The MVP That Never Ships: When the Finish Line Keeps Moving

contact@corebaseit.com (Vincent Bevia) — Fri, 28 Aug 2026 00:00:00 +0200

An MVP that absorbs every new request stops being a learning instrument and becomes an unbounded delivery programme. The core journey may already work. Pilot users may already be generating feedback. The label “MVP” can still survive for months because each discovery is treated as a prerequisite for finishing rather than as input to the next increment.

This is usually not a failure of engineering craft. It is a failure of release-boundary governance: the team never separates what must be true to exit the MVP from what is valuable enough to put on the roadmap.

This post defines MVP as a learning boundary, shows how pilot findings get misclassified, explains why late scope hits architecture harder than the calendar suggests, and outlines two practical controls — an exit gate and a change gate — that let product evolve without moving the finish line.

MVP is a learning boundary, not a miniature finished product

Teams often treat MVP as “the first production version of the complete product.” That definition has no end state. There will always be another merchant, market, integration, edge case, regulatory ask, or operational improvement.

A workable definition:

The smallest version of a product that can test the important assumptions with real users under realistic conditions.

An MVP is therefore not only a feature list. It is a learning boundary: state a hypothesis, build enough to test it, expose the system to reality, measure, then decide.

The decision after Measure & Learn is the boundary that matters. Without it, every discovery can be rewritten as “still required for MVP,” and the MVP never ends.

In payment and POS programmes the same pattern shows up around pilot merchants, SoftPOS or SmartPOS certification paths, and scheme or acquirer checklists: each new “must have before go-live” can be real, but not all of them belong inside the same exit criteria.

The moving finish line

An initial MVP might look like this:

After pilot feedback, the same programme often becomes:

Requirements should change. Pilots exist to surface unknowns. The failure mode is absorbing every discovery inside the same delivery boundary, with no accepted phrase for:

Important. Not part of this increment.

Pilot feedback is not automatic proof that the MVP is unfinished

Real users will find gaps. That is the point. Classify the finding before expanding scope:

Finding	Typical treatment
Critical defect, security issue, compliance blocker, data integrity failure	Fix in current release
Agreed MVP acceptance criterion not met	Fix in current release
Operational blocker	Evaluate; usually fix if it prevents safe pilot operation
New customer request, additional integration, market expansion	Next increment / backlog
UX improvement / nice-to-have	Prioritize on the roadmap

Not everything discovered during an MVP belongs to the MVP. Defects against agreed behaviour usually do. New capabilities usually do not — unless they were already written into the exit criteria.

Late scope has disproportionate system cost

Continuous finish-line moves are not only schedule problems. They rewind parts of the delivery lifecycle:

A two-day code change near a release boundary can become a two-week system change. Architecture absorbs that cost quietly: temporary MVP compromises (manual ops, limited config, simpler integrations, thinner recovery) remain in place while product expectations keep rising. Temporary architecture becomes permanent architecture under production-scale demand. That is how architectural debt accumulates without a dramatic incident.

Freeze the release boundary, not the product

Do not stop accepting requirements. Freeze which release owns them.

The governance question is not “Is this valuable?” It is:

Is this required to satisfy the agreed MVP acceptance criteria, or does it enter the next product increment?

Value and release criticality are different axes. Teams need both.

Define an MVP exit gate before build

Write exit criteria before development starts. Example shape:

MVP Exit Criteria
✓ Core journey works end-to-end
✓ Security / compliance requirements for this pilot satisfied
✓ Required operational monitoring and support path exist
✓ No critical production defects against agreed behaviour
✓ Pilot users can complete the target workflow
✓ Reliability within agreed thresholds
✓ Key product hypothesis can be evaluated with the evidence collected

When those conditions are met, MVP is complete — not “complete unless someone invents another feature.” Who signs the gate (product, engineering, compliance, operations) should be named; an unsigned checklist is theatre.

Use a change gate during pilot

Once pilot validation starts, route new asks through a binary test:

“Blocks MVP success” must be concrete: core workflow cannot complete; unacceptable financial or data risk; missing regulatory requirement for this release; unsafe to operate; agreed hypothesis cannot be tested. It must not mean only “this is important.”

MVP → product is a state transition

Treat the programme as a state machine:

The anti-pattern is a self-loop named MVP:

There is no transition. “MVP” has become the name of the entire product-development programme.

This is not Product versus Engineering. Product surfaces opportunity. Business brings customer pressure. Pilots expose gaps. Engineering surfaces technical risk. The missing shared mechanism is which release owns which requirement. A healthy organisation can say both “this is valuable” and “it does not belong in this release” in the same conversation.

What an MVP is for

An MVP exists to reduce uncertainty:

Assumptions → MVP → real-world evidence → learning → product decisions

Once it has produced enough evidence for those decisions, it has done its job. The product should keep evolving. The MVP should not. If every new requirement moves the finish line, the team is not iterating quickly — it is failing to finish an iteration.

References

Ries, E. (2011). The Lean Startup. Crown Business.
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
West, D. (2020). “Scrum Guide 2020 Update — Introducing the Product Goal.” Scrum.org.
Abramovici, A. (2000). “Controlling Scope Creep.” PM Network, PMI.
Project Management Institute — scope change control practice (programme / project governance).
Bevia, V. — Point-of-Sale Systems Architecture, Chapter 6 (boundaries, modularity, deliberate architectural trade-offs): https://corebaseit.com/my-books/
Related: Spike first, ADR second — evidence and release decisions under uncertainty.

Release-Management on Corebaseit — Design System Engineering · POS · Payments · Security