Scoping Version One: What a First Product Really Includes

What MVP scope actually means

MVP scope is the set of decisions about what version one does, plus the engineering decisions version one commits you to. Most advice stops at feature selection. That is necessary, but incomplete.

If you are a stage-0 founder holding an AI or no-code prototype, the real question is not “what is the smallest thing we can build?” It is: which parts of this thing do we make real, and what has to be right underneath it? That second question determines whether version one becomes version two, or becomes a rewrite.

This is why the usual “define the problem, pick the riskiest assumption, use MoSCoW, cut the rest” playbook only gets you halfway there. It tells you what to leave out. It rarely tells you what must not be improvised.

MVP scope is not just feature pruning. It is judgment about what you can safely defer, and what must be architected correctly on day one.

Why the standard scoping advice is necessary but not sufficient

What every guide tells you

The standard guidance is broadly right:

• Identify the core problem.
• Test the riskiest assumption first.
• Prioritize must-haves over nice-to-haves.
• Use manual workarounds where possible.

That framework prevents overbuilding. It helps founders resist the instinct to cram every imagined feature into version one. It is especially useful when the product idea is still fuzzy.

What none of them tell you

The missing piece is that some decisions are expensive to reverse later even if the first release is tiny. A small product can still lock in the wrong:

• data model,
• tenancy and permissions model,
• authentication approach,
• money flow and audit trail,
• service boundaries,
• testing discipline,
• deployment pipeline,
• observability setup.

You can change a homepage headline in an afternoon. You cannot casually unwind a bad tenant model after customers and data exist. You can swap onboarding copy. You cannot cheaply fix a product that stores business-critical records in a shape that no longer fits the actual workflow.

The two-axis scoping test

To scope a first product properly, run every candidate feature through two questions.

Axis 1: Does this feature help us learn what we need to learn?

This is the conventional MVP question. If the feature does not help validate the core assumption, support the primary workflow, or reveal real demand, it is not version-one material.

Axis 2: Is this a decision we can change in a month, or one we will be stuck with?

This is the missing founder judgment. Some decisions are reversible at low cost. Others are structural.

Reversible now:

• UI layout
• copy
• pricing page
• onboarding flow
• most third-party integrations
• manual back-office work

Irreversible cheaply:

• the core data model
• roles, permissions, and tenancy
• authentication and account structure
• billing, refunds, and audit trails
• service boundaries and integration contracts

The decision rule is simple: if a choice is hard to change once users and data exist, it belongs in the version-one architecture conversation even if it is invisible to users.

The day-one standards that do not scale with scope

There is a category of work that should be non-negotiable whether version one has three screens or thirty. These are not “enterprise” extras. They are the foundation that makes iteration possible.

1. Data model and architecture agreed before code

Before the first feature ships, the team should agree on the objects, relationships, and constraints the product will rely on. Not every edge case must be solved, but the shape of the system must be intentional.

This is where stage-0 founders often underestimate cost. A prototype can fake structure. A real product cannot.

2. Mandatory code review from the first commit

Code review is not a process luxury. It is how the team keeps quality, maintainability, and product logic aligned from the start. If you wait until the product is “big enough,” you will already have normalized shortcuts.

3. Automated tests with enforced coverage

Version one does not need exhaustive testing. It does need a baseline that protects the core flows and makes refactoring safe. Without this, every change becomes a gamble.

4. CI/CD from day one

If every release requires heroics, you have not built a product process; you have built a bottleneck. Continuous integration and deployment make the product easier to improve after launch, which is the entire point of version one.

5. Logging and observability

You cannot learn from usage you cannot see. If the product fails, stalls, or behaves unexpectedly, you need enough telemetry to understand why. That matters even more when the first release is intentionally small, because each signal is more valuable.

6. Infrastructure as code and a broken-window policy

Infrastructure should be reproducible, not handcrafted. And small shortcuts should be treated as a cost center, not a badge of scrappiness. A few tolerated exceptions become the product’s operating system.

At Better Software, this is the logic behind starting at stage 0 and putting a working version in users’ hands in weeks: the scope can stay lean only if the foundation is disciplined. The engineering standards in the open-source template and Engineering Handbook make that foundation inspectable rather than aspirational.

How to scope when you already have an AI or no-code prototype

A prototype changes the conversation, but it does not eliminate it. In fact, it makes the distinction between “demo value” and “product value” more important.

What the prototype has proven

A working prototype can prove that users understand the idea, like the workflow, or engage with the promise. It can also reveal whether the problem is real enough to justify further investment.

What it has not proven

It usually has not proven:

• that the data model will survive real usage,
• that permissions and edge cases are safe,
• that the product can be maintained by a team,
• that the workflow can be observed and debugged,
• that future changes will be cheap.

That is why a prototype is a spec, not a starting codebase. You should mine it for workflow insight, phrasing, and priority. You should not assume the underlying implementation is worth preserving.

How to adjudicate the scope argument on your team

Many early teams split into two camps: the founder wants something stable and small; the builder wants the unique features that will differentiate the product. Both instincts can be right, and both can be expensive when treated as opinions.

Use a decision rule instead:

• If a feature does not validate the core assumption, cut it.
• If a technical shortcut will be painful to reverse later, solve it now.
• If the team cannot observe or support the feature reliably, do not ship it yet.

This turns scope debates into a sequence of judgments, not a referendum on taste. It also resolves the false choice between “ship fast” and “build right.” You can do both, but only if you are precise about what belongs to each axis.

A worked MVP scope example: from prototype to first real version

Consider a founder with a prototype for a customer intake workflow. The prototype proves that users will complete the flow and that the business wants the outcome. The temptation is to ship everything the demo can do.

Here is the version-one scope:

• one primary user flow from start to finish,
• one internal admin view,
• manual handling for any non-core edge case,
• one payment path or no payment at all, depending on what is being validated,
• basic notifications only if they are part of the core loop.

And here is what must be right underneath it:

• a normalized data model for the core entities,
• roles and permissions that match the real operating model,
• auth that supports the expected account structure,
• logging for the critical workflow steps,
• automated tests around the main path,
• CI/CD so the team can ship changes safely,
• observability so failures show up before customers do.

Everything else can wait. The result is a product that is intentionally narrow but structurally sound. That is what keeps version one from becoming a dead end.

In real engagements, this is the pattern we see most often: a founder arrives with a prototype that already convinced someone of demand. The actual build is less about recreating the demo and more about turning the underlying workflow into a system that can absorb real users, real data, and real change without collapsing under its own shortcuts.

Questions founders ask about MVP scope

How many features should version one have?

There is no magic number. Version one should have the fewest features required to prove the core value and support the primary workflow. For some products that is one feature. For others, it is a tightly connected set of three or four.

How long should version one take?

Long enough to be real, short enough that you can still learn before the market, the team, or the thesis changes. The timeline should follow the learning risk, not the imagined completeness of the product.

Which comes first, a proof of concept or an MVP?

A proof of concept answers “can this work at all?” An MVP answers “does this solve a real problem for real users in a usable way?” If the technical uncertainty is high, proof of concept comes first. If the idea is already technically plausible, move to MVP.

Is an MVP the same as a prototype?

No. A prototype is usually for exploration and validation. An MVP is a product version intended to be used by real customers, even if narrowly. That difference matters because the engineering bar is much higher.

What is the difference between MVP and full scope?

Full scope is the complete product vision. MVP scope is the smallest responsible slice of that vision that can generate learning without locking in the wrong foundation.

What to do this week

If you are deciding what belongs in version one, take your feature list and put every item into a simple matrix:

• Does this help us learn?
• Is this easy to reverse later?

Keep the items that score high on learning and low on reversibility cost. Cut the items that are neither essential nor hard to change later. Then separately mark the engineering decisions that must be correct on day one: data model, permissions, auth, audit trails, service boundaries, tests, CI/CD, and observability.

That is the practical answer to how to scope an MVP. Not smaller. Clearer. The goal is not to make version one thin; it is to make it sufficiently real that version two is an evolution, not a restart.