Minimum Sufficient Solution¶
Essence¶
Minimum Sufficient Solution is the intervention pattern of building no more solution than the core requirement demands, while still preserving the constraints that make the solution responsible. It is not generic minimalism. It is a disciplined reduction of implemented scope: first define what must be accomplished, then remove features, steps, documentation, rules, or infrastructure that are not needed for that accomplishment.
The archetype is most useful when a solution is becoming large because additions are easy to request and hard to reject. Its central question is: what is the smallest solution that can responsibly work now, and what would tell us that more is needed later?
Compression statement¶
When a problem invites overbuilding, define the minimum sufficient solution that meets the core need, preserves non-negotiable invariants, excludes nonessential additions, and leaves a clear path for later expansion if evidence justifies it.
Canonical formula: Core requirement + preserved invariants + sufficiency test + nonessential feature filter + expansion path -> smallest solution that can responsibly work
When to Use This Archetype¶
Use this archetype when an effort is expanding beyond the requirement it needs to satisfy. Typical signals include feature bloat, overbuilt workflows, excessive documentation, policy language that tries to cover every hypothetical case, or technical architecture that implements speculative future needs before the present one works.
It is especially useful under time, budget, attention, or implementation constraints. A smaller sufficient solution can often be delivered, adopted, tested, maintained, and revised more easily than a comprehensive one. The archetype is also useful when stakeholders are treating every request as a requirement; it gives the team a principled way to say “not now” without pretending the request has no value.
Do not use it as a shortcut for cutting safety, accessibility, legal compliance, equity protections, privacy, auditability, or basic reliability. Those are often part of the minimum, not enhancements.
Structural Problem¶
The structural problem is overbuilding before sufficiency has been defined. A project, process, policy, product, or intervention grows by accretion: one feature for a possible user, one approval for a possible failure, one extra document for a possible handoff, one dashboard for a possible report. Each addition may sound reasonable in isolation, but the combined solution becomes slower, harder to use, harder to maintain, and harder to change.
The deeper tension is that incomplete solutions can fail, but excessive solutions also fail. Overbuilt solutions consume implementation capacity, confuse users, create maintenance obligations, and delay the moment when the core need is actually served.
Intervention Logic¶
The intervention begins by naming the core requirement. A solution cannot be minimum sufficient unless the team can say what it must accomplish, for whom, under what conditions, and at what minimum standard.
Next, the team names protected invariants: the things that must remain true while scope is reduced. These often include safety, legality, accessibility, equity, privacy, reliability, auditability, and usability. This step prevents “minimum” from becoming underbuilding.
Then the team applies a nonessential feature filter. Each proposed feature, step, document, workflow, control, or capability must justify itself by supporting the core requirement or a protected invariant. Items that are useful but not required are deferred, not erased.
The reduced solution is then tested for sufficiency in realistic conditions. Finally, the team defines an expansion path and review triggers so that the minimum can grow when evidence shows that it is no longer sufficient.
Key Components¶
Minimum Sufficient Solution is a disciplined reduction of implemented scope: it builds no more solution than the core requirement demands while still preserving the constraints that make the solution responsible. The Core Requirement anchors the entire archetype by stating the job the solution must perform — for whom, under what conditions, and at what minimum standard — because without it teams cannot distinguish essential from preferred and reduction becomes arbitrary. The Preserved Invariant Set names the constraints that cannot be sacrificed while simplifying: safety, legality, accessibility, equity, privacy, auditability, and reliability are part of sufficiency rather than optional enhancements, which prevents "minimum" from becoming underbuilding. The Nonessential Feature Filter then tests each proposed part of the solution against the core requirement and the protected invariants; a part stays only if the solution would fail without it, while useful-but-not-required additions are deferred, simplified, or removed. The Sufficiency Test checks whether the reduced solution actually works in realistic conditions through user tasks, pilots, edge-case reviews, compliance checks, or simulations, keeping the archetype grounded in use rather than builder intuition.
The remaining components keep the reduced solution from hardening into either permanent under-solution or silent neglect of what was set aside. The Expansion Path keeps useful but nonessential additions visible for later consideration, letting the system start small without pretending the first minimum will remain enough forever. The Review Trigger specifies what evidence — higher volume, repeated failures, user harm, unmet edge cases, support burden, or changed regulation — should reopen the boundary, which makes deferral accountable rather than indefinite. The Deferred Enhancement Backlog records additions that were considered and postponed, preventing both scope creep and silent neglect by giving deferred work a visible home. Finally, the Exception Rule protects cases where the minimum path is not enough, which matters especially in high-stakes or equity-sensitive contexts where rare cases cannot simply be optimized away. Together these components make sufficiency active and reviewable instead of letting "minimum" become either a euphemism for austerity or a one-time judgment that quietly decays.
| Component | Description |
|---|---|
| Core Requirement ↗ | The core requirement states the job the solution must perform. It anchors the entire archetype. Without it, teams cannot distinguish “essential” from “preferred,” and reduction becomes arbitrary. |
| Preserved Invariant Set ↗ | The preserved invariant set names the constraints that cannot be sacrificed while simplifying. This is where safety, accessibility, equity, legality, privacy, auditability, and reliability belong. These are not decorative additions; they define what responsible sufficiency means. |
| Nonessential Feature Filter ↗ | The nonessential feature filter tests each proposed part of the solution. A part stays only if the solution would fail the core requirement or a protected invariant without it. Otherwise, it is deferred, simplified, or removed. |
| Sufficiency Test ↗ | The sufficiency test checks whether the reduced solution actually works. This may involve user tasks, acceptance criteria, pilots, edge-case reviews, operational walkthroughs, compliance checks, or simulations. The test keeps the archetype grounded in use rather than builder intuition. |
| Expansion Path ↗ | The expansion path keeps useful but nonessential additions visible for later consideration. It lets the system start small without pretending the first minimum will be permanently enough. |
| Review Trigger ↗ | The review trigger specifies what evidence should reopen the boundary: higher volume, repeated failures, user harm, unmet edge cases, support burden, changed regulation, or stakeholder feedback. It makes deferral accountable. |
| Deferred Enhancement Backlog ↗ | A deferred enhancement backlog is optional but often useful. It records additions that were considered and postponed. This helps prevent both scope creep and silent neglect. |
| Exception Rule ↗ | An exception rule protects cases where the minimum path is not enough. This is especially important in high-stakes or equity-sensitive contexts where rare cases cannot simply be optimized away. |
Common Mechanisms¶
| Mechanism | Description |
|---|---|
| MVP-like Scoping ↗ | MVP-like scoping is a common implementation mechanism, especially in product and service contexts. It should not be confused with the archetype itself. The archetype is broader and applies to processes, policies, documentation, infrastructure, and intervention packages. |
| Minimum Viable Process ↗ | A minimum viable process is the smallest recurring workflow that performs its function. It may reduce meetings, approvals, forms, or handoffs while preserving accountability and escalation. |
| Lean Policy Design ↗ | Lean policy design creates the simplest rule or governance structure that can achieve the policy purpose. It avoids building a comprehensive regime before the immediate governance problem requires it. |
| Essential Feature Set ↗ | An essential feature set is an artifact that lists the capabilities required for the solution to work. It separates launch-critical or implementation-critical features from enhancements. |
| Minimum Viable Documentation ↗ | Minimum viable documentation gives users and operators enough information to act correctly, maintain the solution, hand it off, or escalate problems. It is not a refusal to document; it is documentation scoped to use. |
| Simple Intervention Package ↗ | A simple intervention package bundles the few elements needed to produce a target effect. It is useful in public health, education, community programs, and organizational change where implementation capacity is limited. |
| Pilotable Solution ↗ | A pilotable solution makes the minimum testable in a bounded context. The pilot is a mechanism for validating sufficiency; it is not automatically the archetype itself. |
| Must/Should/Could Filter and Scope-Cut Review ↗ | Must/Should/Could filters and scope-cut reviews are practical sorting mechanisms. They help teams classify proposed scope, remove unnecessary parts, and preserve visibility for deferred improvements. |
Parameter / Tuning Dimensions¶
The main tuning dimension is the strictness of the sufficiency threshold. A looser threshold favors speed and low burden; a stricter threshold favors completeness, safety, and confidence.
A second dimension is reversibility. If omitted scope can be added later cheaply, the minimum can be smaller. If expansion is expensive or impossible, the initial solution should include more future-critical capacity.
A third dimension is edge-case tolerance. Low-stakes, common-case solutions can sometimes rely on simple exception handling. High-stakes systems need stronger tail coverage, appeal paths, or reserves.
A fourth dimension is stakeholder tolerance. Some contexts accept staged delivery; others require visible completeness, legitimacy, or ceremonial robustness before the solution can be trusted.
A fifth dimension is maintenance capacity. A minimum that is easy to build but hard to maintain is not truly sufficient.
Invariants to Preserve¶
The solution must preserve its core function. It must still do the job it exists to do.
It must preserve safety, legality, accessibility, equity, privacy, auditability, and reliability where those matter. These constraints are part of sufficiency, not optional enhancements.
It should preserve operational usability. The intended users and operators must be able to understand, adopt, and maintain it.
It should preserve an expansion path. Starting small is safer when the system can add capability, control, documentation, or capacity as evidence arrives.
It should preserve accountability for deferral. Excluded scope should be visible, reasoned, and reviewable.
Target Outcomes¶
The immediate target outcome is faster responsible delivery: the core need is served without waiting for optional scope.
The second target outcome is reduced implementation and maintenance burden. Fewer parts mean fewer things to train, document, debug, govern, and revise.
The third target outcome is a clearer solution boundary. Stakeholders can see what is required now, what is deferred, and what evidence would justify expansion.
The fourth target outcome is reduced overengineering. Speculative features and controls stop blocking action.
The fifth target outcome is improved adaptability. A smaller solution is often easier to change when requirements, users, or constraints become clearer.
Tradeoffs¶
Minimum sufficiency trades completeness for speed and clarity. This is valuable only when the missing scope is genuinely nonessential or safely deferrable.
It trades broad edge-case coverage for lower burden. That tradeoff can be dangerous if rare cases involve high harm, legal obligation, or vulnerable users.
It trades stakeholder satisfaction for focus. Some stakeholders may feel ignored when their preferred additions are deferred, even if the core solution is sufficient.
It trades mature appearance for adaptability. A smaller solution may look less impressive than a comprehensive design, even when it is more usable and easier to improve.
Failure Modes¶
The most common failure mode is underbuilding: the team defines the core requirement too narrowly and declares a solution sufficient before realistic use proves it.
A second failure mode is treating protected invariants as optional. Safety, accessibility, equity, privacy, legality, and reliability can be mistakenly cut as “extra.”
A third failure mode is false sufficiency from idealized testing. A solution may work for expert builders in clean conditions but fail for real users under real constraints.
A fourth failure mode is permanent deferral. Useful additions are postponed with no owner, trigger, or review cadence, so the minimum becomes a stagnant under-solution.
A fifth failure mode is austerity disguised as minimalism. The language of minimum sufficiency can be misused to justify cost cutting, service denial, or burden shifting.
Neighbor Distinctions¶
Minimum Sufficient Solution is distinct from Parsimony Filter. Parsimony Filter removes unsupported assumptions or complexity; Minimum Sufficient Solution defines the smallest implemented solution that satisfies a requirement.
It is distinct from Bounded Approximation. Bounded Approximation simplifies representation or computation while bounding error; this archetype scopes a solution.
It is distinct from Minimum Effective Intervention. Minimum Effective Intervention focuses on the least dose or intensity that produces an effect; Minimum Sufficient Solution focuses on the smallest solution form, which may include features, process, documentation, and expansion logic.
It is distinct from Minimum Viable Learning Release. A learning release is sized to generate feedback and validate assumptions; a minimum sufficient solution is sized to satisfy a known requirement. They may overlap, but their success tests differ.
It is distinct from Marginal Stop Rule. Marginal Stop Rule decides when further increments are no longer worth the cost; Minimum Sufficient Solution defines the initial sufficient boundary.
Variants and Near Names¶
Recognized variants include Minimum Viable Process, Essential Feature Set, Minimum Viable Documentation, and Simple Intervention Package. These remain under the parent when they use the same logic: define the requirement, preserve invariants, remove nonessential scope, test sufficiency, and preserve an expansion path.
Near names include Minimum Viable Solution, Minimum Necessary Solution, Right-Sized Solution, and Minimum Viable Scope. MVP language should be used carefully. A product MVP is often a mechanism or a learning-release variant, not the whole archetype.
Promotion candidates include Minimum Viable Learning Release and Satisficing Threshold Design. Reconciliation controls preserve them by decision stage, so this draft records them without silently collapsing them.
Cross-Domain Examples¶
In software, a team ships the core workflow, basic recovery, logging, and support before adding personalization or analytics.
In clinic operations, a short intake process keeps the required safety questions and escalation path while removing duplicative fields.
In local government, a temporary permit process starts with one eligibility rule, one review queue, and one appeal path before building a full licensing regime.
In education, a tutoring program begins with a diagnostic prompt, a standard session routine, and progress review before adopting a complex platform.
In technical operations, an internal deployment tool includes authentication, rollback, logging, and a runbook while deferring a custom dashboard.
Non-Examples¶
A bridge design that removes redundancy because most days do not require it is not a minimum sufficient solution. The redundancy may be part of safety sufficiency.
A public benefits form that removes translation, accessibility, or appeal mechanisms just to become shorter is not this archetype. It has removed protected invariants.
A rough forecast is not this archetype; it is closer to Bounded Approximation.
A team that stops refining a design because the next improvement is not worth the cost is using a stop-rule pattern, not necessarily Minimum Sufficient Solution.
A prototype launched only to learn whether users care is closer to Minimum Viable Learning Release or prototype learning if it does not satisfy the core requirement.