Scoping an MVP without painting yourself into a corner
An MVP should be the smallest honest version of the real system, not a throwaway demo. Here is how to cut scope without cutting the foundations you will need in six months.
Vinerals TechnologiesWorkshop notes
MVP has become one of the most abused words in software. It gets used to justify half-built products, ugly shortcuts, and demos that never become systems. Then, a year later, the company is told it needs a full rewrite because “we were just doing an MVP.”
That is not what an MVP is for. A good MVP is the smallest honest version of the real system: enough to put in front of real users, doing real work, on production data. Small does not mean disposable. Small means you chose what to defer, on purpose, without lying to yourself about what you are building.
This piece is for product and ops leads with a limited budget who need something useful soon, and who cannot afford to throw away the first version six months from now.
MVP, prototype, and pilot are not the same thing
People mix these three up constantly. Each has a different job. Picking the wrong one is how you end up with the wrong estimate, the wrong timeline, and the wrong argument in month four.
Prototype.
Built to answer a question: will this workflow feel right, will this integration work, will anyone use it on a phone in a cold warehouse? A prototype can be rough. It can run on fake data. It is allowed to be thrown away once you have the answer.
Pilot.
A controlled run with a small group on real data for a fixed period. You are testing adoption and failure modes before you widen the rollout. A pilot can be built on MVP-quality code, but the goal is learning, not permanence.
MVP.
The first production slice of the system you intend to keep. Real users, real data, real hosting. You cut features, not foundations. What ships should be extendable without a rewrite if phase two goes ahead.
If you only need to learn whether an idea works, say prototype. If you need something your team will run the business on next quarter, say MVP and scope accordingly. Mixing the words mixes the expectations, and that is where trust breaks down.
What to cut, and what to protect
Cutting scope is the whole game. The mistake is cutting the wrong layer. Polish, reports, and edge cases are fair game. Architecture, data model, and auth are usually not.
Safe to defer in v1
Nice dashboards.
A simple table with filters beats a chart wall nobody opens.
Rare edge cases.
Handle the path 90 percent of users take. Document the rest for manual handling until volume justifies automation.
Secondary roles.
Launch with one user type doing one job. Add the warehouse view or the manager approval loop in phase two.
Cosmetic perfection.
Clean and clear beats flashy. You are not launching a marketing site.
Automations you have not validated.
A human step in the loop is fine for v1 if it keeps the system understandable.
Protect even when the budget is tight
Data model.
Names, relationships, and history. Getting these wrong means painful migrations later. Sketch the entities you will still need at scale, even if v1 only uses half of them.
Authentication and permissions.
Even a simple role model is cheaper to build early than to bolt on after twelve months of “everyone is admin.”
Integration boundaries.
How you talk to the accounting system or the CRM. A thin, well-defined connector beats a tangle of one-off scripts.
Audit trail for anything regulated or financial.
If you will need it eventually, design for it now. Retrofitting logs is miserable.
Deployment and environments.
Staging, backups, a path to production that does not live on someone’s laptop. Boring infrastructure is part of the MVP if the MVP is real.
A useful question in every scoping meeting: if we never get phase two funding, would we still be glad we built v1 this way? If the answer is no, you are building a prototype and should price and plan it as one.
Phasing without rewrites
Good phasing feels like uncovering layers, not throwing away floors. Each phase should add capability to the same core, not fork into a parallel system nobody maintains.
Slice by user job, not by screen count.
Phase one: field tech logs an inspection. Phase two: manager approves and billing pulls from it. Same record, new views and rules. Not a second app.
Name what each phase unlocks.
“Phase two” should mean a specific outcome, not “everything we ran out of time for.”
Keep one database, one auth system, one deployment.
Multiple stacks for multiple phases is how SMEs end up paying twice.
Budget phase two before you start phase one.
Not the exact dollars. The rough shape. If there is no credible path to phase two, scope phase one as a complete product that stands alone.
Draw a simple diagram: boxes for user groups, arrows for data flow, shaded areas for “this phase” vs “later.” If the diagram needs a second diagram to explain phase two, the phasing is probably fantasy.
Acceptance criteria that prevent scope fog
“Done” is where MVPs go to argue. Write acceptance criteria before build starts, in language a non-developer can verify in an afternoon.
Behaviour, not adjectives.
“User can submit a form offline and it syncs when back on Wi-Fi” beats “works well on mobile.”
Real data volumes.
“Handles last month’s actual export file without timing out” beats “performant.”
Named roles.
“Warehouse lead can reassign a location; viewer cannot” beats “role-based access.”
Failure cases.
What happens when the integration is down, when validation fails, when someone duplicates a record. Silence is not acceptance.
Out of scope, listed explicitly.
The features you are not shipping in v1 should appear in the same document as the ones you are. That is how you stop “I thought that was included.”
Attach the criteria to the brief and the quote. When scope creep arrives dressed as a small tweak, you have a shared reference that is not memory.
When “phase 2” is a lie
Phase two is sometimes a polite fiction: a way to win the deal now and defer the hard conversation about money until everyone is emotionally invested. A few signs the phasing story will not hold.
Phase one is unusable without phase two.
If v1 does not deliver value on its own, it is not an MVP. It is a down payment on a gamble.
Nobody has budget authority for phase two.
“We will find the money later” is not a plan. Later arrives with new priorities.
Phase two scope is “everything else.”
If you cannot name it, you cannot price it, and it will not happen on schedule.
The technical foundation assumes phase two that may never come.
Over-building for a future that is uncertain is its own failure mode. Build extendable, not empty.
Success metrics only exist for the full vision.
If you cannot measure whether phase one worked, you will not get a honest yes for phase two.
Honest phasing sounds smaller. “We will ship logging and billing export in nine weeks. If adoption hits X, we scope approvals next.” That is a plan you can fund and defend.
A scoping checklist before you sign
Run this with your shop before the contract is inked. It takes an hour and saves a season of regret.
1. Are we building an MVP, a prototype, or a pilot?
One word. Agreed definition.
2. What job does v1 complete for a real user?
In one sentence, without mentioning future phases.
3. What foundations are protected in the estimate?
Data model, auth, integrations, ops. Named explicitly.
4. What is explicitly out of v1?
Written down, not implied.
5. What are the acceptance criteria?
Testable by you, not only by the dev team.
6. If phase two never happens, is v1 still worth what we paid?
If no, rescope or reprice.
A shop that pushes back on fuzzy scope is doing you a favour. A shop that says yes to everything and cuts foundations is selling you a prototype at MVP prices.
The point of an MVP is not to be small for its own sake. It is to be honest: about what users need first, about what must last, and about what you are willing to defer without fooling yourself.
We build software by hand for SMEs, and most of our best projects start with a tight first slice that still feels like the real thing. If you are scoping an MVP and want a plain read on what to cut and what to protect, we are glad to walk through it with you. Bring the one-sentence job and the list of what you are tempted to defer. We will start there.
