A Guide to MVP Development: What Belongs in the First Version, and What Does Not
“Let’s just build an MVP first” means, in a great many meetings, “let’s build a cheap version first.” That is the most common and most expensive misunderstanding of the idea.
The point of an MVP was never to save money. It is to obtain, at the smallest possible cost, a piece of information you do not currently have. Get that straight and the answer to what belongs in the first version, and what does not, tends to surface on its own.
An MVP is not a half-finished product; it is an experiment
Behind every new product sits a pile of assumptions: somebody needs this, they are willing to pay for it, they will use it the way we imagine, we can reach them. Until the product is live, all of those are guesses.
The job of an MVP is to identify the single most fatal assumption — the one that, if wrong, means the whole business does not work — and validate it with the least possible investment.
So the right opening move is not “which features are we building,” but:
“If only one thing can be wrong, which one being wrong makes everything else pointless?”
By way of example: if your assumption is that restaurant owners are willing to manage delivery orders from their phones, the first version needs a flow that genuinely carries a single order through end to end — not a half-finished product with member accounts, coupons, analytics dashboards, and multiple languages all at once.
The test of whether an MVP is well designed: once it is finished, can you state clearly whether the assumption holds or does not? If you still cannot tell, it was not an MVP. It was just a small product.
Four common misunderstandings
One: an MVP means halving the features. Build ten features at half completeness and you get ten features nobody can use. The correct approach is to build one complete, usable flow and nothing else.
Two: an MVP can be rough. Users do not lower their standards because you called it a beta. If the flow stalls, data disappears, or the screens are hard to interpret, the negative feedback you receive cannot distinguish “I do not need this” from “this is hard to use” — which means you validated nothing.
Three: an MVP has to be an app or a system. Sometimes the fastest way to validate is a form, or a single explanatory page with a booking button, or a person handling things manually behind the scenes. Confirm somebody wants it before deciding whether to automate it.
Four: finishing the MVP means finishing the product. What an MVP produces is knowledge, not a finished product. The real building phase starts after validation.
Deciding what goes in the first version
Cut along a single line: map the shortest end-to-end path a user takes to accomplish the thing they came for, build every step on that path, and build nothing off it.
For an online booking service, the path might be: see the service, choose a time slot, leave your details, receive a confirmation.
Every step on that line has to be complete and usable. There can be no gap where a slot gets booked but no confirmation arrives.
Everything off that line goes on the “later” list:
| Common “later” items | First-version substitute |
|---|---|
| Member accounts and sign-in | Identify people by email or phone number |
| Admin interface | Read the database or a spreadsheet and handle things manually |
| Payment integration | Bank transfer or payment on site |
| Analytics and reporting | Export and total the numbers by hand |
| Notification system | Send messages manually |
| Multiple languages | Start with the primary language |
| Permission management | One role only in version one |
These substitutes are entirely workable while user numbers are small, and they put you close enough to see real usage behavior — information that automation actually takes away from you.
The line that matters: what you can simplify is scale and automation. What you cannot simplify is the completeness of the user experience and the correctness of the data. If a user’s data is lost in version one, what you lose is not only the data but that person.
Choosing technology: good enough, and replaceable
The two technical mistakes made most often in the early stage point in opposite directions and end equally badly.
Over-building. With no users yet, constructing an architecture that can carry heavy traffic, splitting into microservices, building complete automated testing and deployment pipelines. Before demand is validated, most of that investment gets discarded as the direction shifts.
Choosing a road with no exit. Picking an off-the-shelf platform or tool with deep lock-in for the sake of speed. It genuinely is faster in the short term, but the data cannot be extracted and the logic cannot be ported, so expanding later means rebuilding from scratch.
The sensible principle is good enough, and replaceable:
- Choose mature technology with good documentation and people available to maintain it. Obscure technology becomes a recruiting obstacle when you want to grow the team.
- The data is yours, and it has to be exportable. Whatever service you use, confirm you can extract your data in full at any time.
- Separate what will change from what will not. Interfaces and business rules change constantly; the data model and account system are relatively stable and deserve to be thought through on day one — those two are the hardest things to change later.
- Do not optimize in advance for imagined scale. Growing user numbers is good news, and there will be time to handle it then.
- Source code and account credentials have to be in your hands. This matters especially when the work is outsourced.
If technology selection is hard for you to judge, a neutral third-party opinion helps. NETVANA’s tech consulting service covers technology selection and architecture assessment; for details, see the software services overview.
When a rewrite is warranted
“You have to rewrite after the MVP” is a myth, but there are genuine moments when a rewrite is right. The basis for that judgment is not how attractive the code is:
Signals that a rewrite is warranted
- The product direction has fundamentally changed and the original data model no longer fits
- Every new feature requires changes in many unrelated places, and the cost of change keeps rising
- Errors appear that nobody can locate, and nobody dares touch that part of the code
- The performance problems come from the architecture itself and tuning has reached its limit
Signals that a rewrite is not warranted
- A new engineer thinks the code is ugly
- Somebody wants to move to a newer technology
- A few parts are badly written — those should be improved incrementally, not demolished
The middle path. In most cases, incremental replacement is safer than a full rewrite. Split the system into sections, replace one at a time, and confirm everything still works after each. During a full rewrite the product typically stops evolving for months, and that opportunity cost is routinely underestimated.
Building an MVP with an outsourced team: five things to watch
For startups and small businesses, the first version is frequently built externally. That combination can be very efficient, with a few preconditions.
One: your side needs somebody who can decide what not to build. The core work of an MVP is subtraction, and subtraction can only be settled by someone who understands the business and holds the authority. A vendor can advise, but cannot make your commercial trade-offs for you.
Two: write the assumption you are validating into the requirements document. Do not hand over only a feature list. When the vendor knows what you are trying to validate, they have the chance to propose cheaper routes — such as “handle this part manually and save several weeks.”
Three: deliver in phases, with something usable at every phase. “We’ll look when development is finished” is too risky for an MVP, because the value of an MVP lies in getting feedback early. NETVANA works in two-week sprints with a fixed demo at the end of each; see the software development process.
Four: write the conditions for future expansion into the contract. Ownership of source code and documentation, whose name the third-party service accounts are in, and how subsequent maintenance and new features are priced. A successful MVP is where the real investment begins, and being locked to a single vendor at that point leaves you with very little negotiating power. For the relevant clauses, see How to Choose a Software Development Company.
Five: reserve budget and time for what happens after validation. A common mistake is spending the entire budget on version one, reaching a result, and having no resources left to act on it. The sensible approach is to spend only part on version one and keep resources for the inevitable work of adjusting to feedback.
As for whether to outsource entirely, build a team, or run a consultant alongside a small team, see the trade-offs in Outsourcing vs. an In-House Team. For the cost structure of app projects, see the Complete Guide to App Development Costs.
After the MVP launches: what to look at
Shipping it is only the start. The real value is in how you read the results.
Watch behavior, not just opinions. A user saying “this is great” and a user coming back a second time are two different things. What to look at: how many people complete the whole main path, which step they leave at, and whether anyone returns unprompted.
Talk to users yourself. Early on, user numbers are small enough to interview one by one. That qualitative information becomes unobtainable once you scale.
Watch how they misuse your product. Users applying it to something you never envisaged is often the most valuable signal available.
Set explicit criteria for the judgment. Agree before launch what result means the assumption holds, what result means the direction needs adjusting, and what result means stopping. Without that set in advance, you will read the numbers selectively in your own favor afterwards.
The hard part of an MVP was never the technology. It is the discipline — resisting the urge to stuff every feature you can think of into the first version, and resisting the urge to erect a tower block before anyone has shown up to use it.
If you have a product idea and want to work out how far the first version should go and which method of validation is cheapest, talk to NETVANA. Define the question you are validating first, then decide what to build.
Further reading: for estimating a development budget, see the Complete Guide to App Development Costs and How Website Costs Are Calculated. For the trade-offs in team structure, see Outsourcing vs. an In-House Team. For writing a requirements document without an engineering background, see How to Write Software Requirements; and for how scope creep turns into schedule slip, see Why Software Projects Run Late. For prioritizing features once the first version is live, see Where a Product Goes After Launch. While scoping your first version, a low-code platform might get you there faster; see Are Low-Code and No-Code Platforms Right for You. The same what-belongs-in-version-one logic applies to a marketplace; see Marketplace Platform Development. To settle the format before scoping version one, see Native App, Responsive Web, or PWA.
