When a founder tells us an MVP went badly, the problem is almost never that the code was poor. It is that the money went on the wrong half of the product.
A first version that does three things properly can be tested against real users within a couple of months. A first version that does fifteen things adequately takes three times as long, costs three times as much, and still cannot answer the one question the whole exercise existed to answer: will anyone actually use this?
This is about how to avoid the second outcome.
What an MVP actually is
The phrase has been stretched to mean "the cheap version", which is why so many of them disappoint. A minimum viable product is not a discount product. It is an experiment with a specific job: to find out whether your core assumption about your users is correct, using the smallest build that can honestly test it.
Two words carry the weight.
Minimum means the smallest thing that can produce a trustworthy answer. Not the smallest thing you could ship — the smallest thing that genuinely tests the idea.
Viable means somebody can actually complete the job they came to do. A booking platform where a user can find a slot but not pay for it has not tested whether people will book. It has tested whether people will browse.
That distinction decides your scope. For every feature, the question is not "is this useful?" — most features are useful. It is: if we leave this out, can a user still complete the one journey we need to observe? If yes, it waits.
Finding the features that earn their place
Start from the journey, not the feature list.
Write down, in plain sentences, the single path a user takes through your product when it works. For a marketplace: a customer searches, finds a provider, picks a time, pays, and both sides get a confirmation. For an internal tool: a staff member opens a job, records what they did, and it appears on this week's invoice.
Now everything divides into three groups.
On the path. Without it, the journey stops. Search, availability, checkout, confirmation. These are your MVP.
Beside the path. Real needs that do not block the journey. Saved favourites, profile photos, a referral scheme, exporting to CSV. These wait, and most of them wait happily.
Behind the path. Things that only matter at a scale you do not have yet. Multi-currency pricing, granular role permissions, an audit log, a mobile app. These wait longest, and some are never needed in the form you first imagined.
The uncomfortable part is that founders are usually right that the "beside the path" features matter. They do — later. Building them now means spending the budget that was supposed to buy you the information you needed first.
Two things people cut that they should not
A couple of items get grouped with "later" and should not be.
Anything that handles money or identity. Payments, authentication and access control are the parts where cutting corners creates liabilities rather than technical debt. Use established services — a payment provider, a mature authentication library — rather than building your own, but do not defer getting them right.
The one measurement that tells you whether it worked. If you cannot see how many users reached the end of the journey, you will finish the MVP with opinions instead of evidence, and the next decision will be a guess.
Where overengineering actually happens
Overengineering rarely looks like showing off. It looks like being responsible.
Building for scale you do not have. Queues, caches, microservices, multi-region hosting and load balancers all solve problems a product with forty users does not have. They cost development time now and operational complexity forever. A single well-built application on one server handles far more traffic than most founders expect — and when it genuinely stops coping, you will have revenue and real usage data with which to make a better decision than the one you would have guessed at today.
Building an admin panel before you need one. Many early operations can run on direct database access or a spreadsheet export, handled by the founder. A full custom back office is often the largest single piece of an MVP, and it is almost always needed less urgently than it feels.
Configurability nobody asked for. Every setting you make adjustable is a decision you have deferred and a code path you now have to test. Hard-code it. Change it when someone asks.
Abstraction in advance. Interfaces designed for a second payment provider, a second language, a second tenant. If there is no second one yet, the abstraction is a guess about what the second one will need — and guesses about future requirements are wrong often enough that the abstraction usually has to be redone anyway.
The opposite failure is real too. An MVP that cannot be extended without a rewrite is not cheap, it is a prepayment on a bigger bill. The line we hold is roughly: simple structure, sound fundamentals, no speculative machinery. A clean data model, sensible boundaries between parts of the application, real tests on the paths that involve money — and nothing built for a problem you have not met.
Practical technology decisions
The honest answer to "what should we build it in?" is: something your team can maintain, that fits the shape of the problem, and that will still be supported in five years.
That is less exciting than a framework comparison, but the alternative — picking a stack because it is fashionable — has a predictable ending. The MVP ships, the one developer who knew that stack moves on, and the founder discovers that hiring for it costs a premium.
Some things that do genuinely matter at this stage:
- Does it have an obvious answer for the boring parts? Authentication, forms, validation, file uploads, background jobs, email. A stack with mature, well-documented solutions for these saves weeks.
- Can you host it simply? A deployment story that needs a dedicated platform engineer is a recurring cost on top of the build.
- Is the talent pool real? Not "is it popular on social media" but: could you hire someone to maintain this next year, at a price you can pay?
- Does it suit the work? Content-heavy, SEO-dependent products have different needs from data-heavy internal tools. We have written a balanced comparison of PHP and Next.js for business applications that walks through how that choice plays out in practice.
What matters much less than founders expect: which of two mainstream, well-supported options you pick. Both will work. The build quality and the scope discipline will decide the outcome far more than the framework will.
Planning for growth without paying for it now
You can leave room for the future without building it. The trick is that the things which are expensive to change later are mostly cheap to get right now, and they are not the flashy ones.
The data model. Renaming a field is easy. Discovering that your schema assumed one provider per booking when the business needs several is not. Spend real time here — it is the highest-leverage hour in the project.
Clear boundaries. Keep business logic out of your templates and your controllers thin. This is not architecture astronautics; it is the difference between adding a mobile API later in a week or in a quarter.
Migrations from day one. Every schema change as a versioned migration, from the first one. Retrofitting this onto a live database is miserable.
Somewhere to put the next thing. You do not need a plugin system. You need the next developer to be able to see where a new feature would go.
Common mistakes we see
- Treating the MVP as version one of the real product. It is an experiment. Some of it should be thrown away, and planning for that makes it cheaper to throw away.
- Asking for a fixed quote on an undefined scope. You will get a high number, a narrow interpretation of it, or both. Define the journey first, then price it.
- Hiring for the build but not the month after launch. The first two weeks of real usage generate more useful work than the preceding two months of development. If nobody is available to act on it, the learning is wasted.
- No decision rule. Agree, before you start, what result would mean "continue", "change direction" and "stop". Without it, every outcome gets interpreted as encouraging.
- Designing the whole product up front. Full designs for screens that may never exist is budget spent on a hypothesis. Design the journey; sketch the rest.
- Skipping the launch logistics. Hosting, domains, backups, an error-reporting tool and a basic analytics setup are small jobs that are consistently forgotten until the week of launch, when they become urgent.
When it is worth bringing in an experienced partner
Not always. If you have a technical co-founder with the time to build it, that is usually the cheapest and fastest route available to you.
It is worth bringing someone in when:
- You are non-technical and the product is the business. Not for the code, for the scoping. A partner who has watched MVPs succeed and fail will push back on the feature list, and that pushback is the part that saves the money.
- The domain has real consequences. Payments, personal data, regulated industries, anything where a mistake costs more than a sprint.
- You have inherited something half-built. Assessing whether an existing codebase is worth continuing is a specific skill, and the answer is genuinely sometimes yes.
- You need the thing to outlive the build. Someone who will still be reachable in eighteen months is worth more than someone who is 20% cheaper today.
What to look for: a partner who asks what you are trying to learn before asking what you want built, who will tell you a feature should wait, and who talks about the month after launch as part of the project rather than as an upsell. Our own process is built around agreeing the scope before anyone writes code, because that is where MVP budgets are won or lost.
In short
An MVP is an experiment, and its budget is the cost of getting an answer. Spend it on the one journey that tests your idea, build that journey properly, and let everything else wait until real users have told you what they actually need.
The founders who get the most from a first version are not the ones who spent the most. They are the ones who were clearest about what they were trying to find out.
