By Sakshi Shah · 6 October 2026 · 13 min read
MVP Development: What Should You Build in Your First Release?
A practical guide to MVP development: find the core loop, sort features into build, fake and later, and get right the few foundations that are costly to change.
Introduction
Every product founder eventually faces the same list: forty features, all of which feel essential, and a budget and timeline that can deliver perhaps twelve of them. The temptation is to squeeze in as many as possible, or to cut them all equally and ship a thin version of everything. Both usually fail. The first launches late with a product nobody has validated; the second launches on time with a product that does nothing well enough for anyone to care.
Good MVP development starts from a different question. Not "which features can we afford?" but "what is the one thing we need to learn, and what is the smallest product that will teach it to us?" Answer that clearly and most of the feature list sorts itself. This piece walks through how to identify what your first release must prove, how to find the core loop that proves it, how to sort the remaining features into what to build properly, what to build minimally, what to do by hand and what to leave for later — and which few technical foundations you must get right from day one, because they are the ones that are expensive to change once real customers exist.
An MVP Is a Question, Not a Small Product
The phrase "minimum viable product" is widely misunderstood as "the cheapest version of the product we eventually want". It is better understood as the smallest thing you can put in front of real users that tests whether your central assumption is true.
Every new product rests on a handful of risky assumptions. Will the people we think have this problem actually recognise it? Will they change how they work to use our solution? Will they pay what we need to charge? Can we build it at a cost that makes the business work? Some of those assumptions are far riskier than others, and the first release should be designed around the riskiest one.
That shift in thinking changes decisions quickly. If the biggest risk is whether customers will pay, then billing belongs in the MVP, even in a rough form, and a polished dashboard does not. If the biggest risk is whether users will complete a new workflow at all, then that workflow needs to be excellent and almost everything around it can be basic. The word "viable" matters too: the product has to be good enough at its one job that users take it seriously. A minimum product that is not viable teaches you nothing, because users reject it for reasons unrelated to your idea.
Find the Core Loop
Most successful products have a core loop — a short cycle a user goes through that delivers the product's value and brings them back to do it again. For a field inspection tool, it might be: assign an inspection, complete it on site, generate the report, share it with the client. For a B2B ordering portal: browse the catalogue, place an order, track it, reorder. The first release exists to make that loop work reliably and to show whether people keep coming back to it.
To find your loop, write down, in plain language, the smallest sequence of steps after which a user would say "that was worth it". Then check each feature on your list against it. Does it help a user get through the loop, or help you see whether they do? If not, it waits. This single test removes more scope than any other technique, and it removes the right scope.
A common trap is designing for several user types at once. A marketplace needs buyers and sellers; an internal tool may have staff, managers and clients. Where you can, launch with the loop for one user type working brilliantly and handle the others more simply — sometimes by hand — until the first loop is proven.
Sort Every Feature Into Four Buckets
With the core loop defined, the full feature list can be sorted. Using four buckets rather than "in" and "out" is what makes a small release feel complete to users.
| Bucket | What goes here | Example: a field inspection SaaS |
|---|---|---|
| Build properly | The core loop, and the foundations that are expensive to change later | Inspection checklist and photo capture, report generation, sign-in, one company's data kept separate from another's |
| Build minimally | Needed for the product to be usable, but not where its value lies | Email notifications only, a simple settings page, a basic admin view for your own team |
| Do by hand for now | Things your team can handle manually behind the scenes while volume is low | Onboarding and importing each customer's templates, invoicing through payment links, custom report branding |
| Later list | Good ideas that do not serve the core loop yet — written down, not forgotten | Native mobile app, accounting integration, analytics dashboards, single sign-on, public API |
The third bucket is the most underused and the most powerful. Early customers rarely know or care whether something is automated. If your team can set up each new account by hand in an hour, you do not need a self-service onboarding wizard for your first twenty customers — and by the time you do, you will know exactly what that wizard needs to do, because you will have done it twenty times.
The fourth bucket matters for a different reason: it lets you say "not yet" instead of "no". A visible, written later list keeps stakeholders confident that their ideas have been heard, and it becomes the starting point for planning the second release once real usage shows which of them matter.
The Few Things You Must Get Right From Day One
"Minimum" does not mean "careless". A small number of technical decisions are cheap to make well at the start and extremely expensive to change once customers and their data exist. These are the corners not to cut, however tight the budget.
The data model — how the core things in your product relate to each other — shapes every screen, report and integration built afterwards. A day spent thinking it through with someone experienced saves months later. Tenant separation, the guarantee that one customer can never see another's data, has to be designed into the data model and every query from the start; bolting it on later is one of the most expensive retrofits a SaaS product can face. Authentication and roles decide who can do what, and a product that starts with "everyone can do everything" rarely finds a painless way back. Identifiers and URLs end up in customers' bookmarks, emails and integrations; changing them breaks things you cannot see.
Everything in the right-hand column can be rough at launch and improved weekly based on what users actually do. This is the balance our SaaS & MVP Development work is built around: a deliberately small first release, on foundations that can carry the next stage of growth.
Decide What Success Looks Like Before You Build
An MVP that launches without agreed success measures tends to produce arguments rather than decisions. Before writing any code, agree what you will measure and what result would mean "keep going", "change direction" or "stop".
- Activation — the share of people who sign up and complete the core loop once. Low activation usually points at onboarding or a confusing first experience.
- Repeat use — the share who complete the loop again in the following weeks. This is the clearest signal that the product delivers value.
- Willingness to pay — conversions from trial to paid, or signed commitments from pilot customers. Enthusiasm in interviews is not the same thing.
- Qualitative feedback — what users say is missing, and, more importantly, what they do instead when the product does not help them.
Build the minimum analytics needed to see these numbers into the first release. An MVP without measurement is just a small product.
Common MVP Mistakes
Building for the demo rather than the user. A product designed to impress investors in a ten-minute walkthrough often prioritises polish on screens users rarely visit over reliability in the loop they use every day.
Too many user types at once. Every additional role multiplies screens, permissions and testing. Launch with one role working well wherever possible.
Automating what could be manual. Self-service onboarding, automated billing and admin tooling are all worth building — after you know the process from doing it by hand.
Launching to nobody. An MVP needs users on day one. Line up pilot customers, a waiting list or a design-partner group before the build finishes, not after.
Skipping the foundations to save time. The fastest MVP is not the one with no tests, no permissions and a data model sketched in an afternoon. It is the one that does not need rebuilding when it succeeds. What happens to products that skip this step is its own subject, covered later this month.
A practical sequence that avoids most of these mistakes:
Scoping workshop
Name the riskiest assumption, define the core loop, sort features into the four buckets and agree the success measures.
Clickable prototype
Put a clickable version of the loop in front of five to ten target users before building it. Fix what confuses them.
Build the release
Build the loop properly on sound foundations, with visible progress every week or two and early deployment to a real environment.
Launch to a small group
Release to pilot users, watch the measures, talk to them weekly, and decide on the next release from evidence.
If you are still working out the budget for this, How Much Does It Cost to Build a SaaS Product in 2026? breaks down where the effort goes and what drives it up.
Conclusion
An MVP is a question you put to the market, and the first release should be the smallest product that answers it convincingly. Identify the riskiest assumption, find the core loop that tests it, and make that loop work well. Sort everything else into build minimally, do by hand, or later — and write the later list down. Spend your care on the few foundations that are expensive to change, keep everything else simple, and measure what happens from the first day.
Done this way, the first release is small enough to ship quickly, good enough to be taken seriously, and built well enough that success means iterating rather than starting again.
Have a product idea and a feature list that keeps growing?
Let's find the core loop together, scope the smallest version worth building, and identify what needs to be designed correctly from day one. Start the conversation.
Frequently Asked Questions
How long should MVP development take?
For a focused product with one core loop, a first release in roughly two to four months is common. If the plan runs much longer, the scope is usually larger than an MVP needs to be, and it is worth revisiting what can move to the later list or be done by hand.
Should an MVP include payments?
If willingness to pay is one of your riskiest assumptions, yes — even in a simple form, such as payment links or manual invoicing. Asking for money early gives far more reliable evidence than asking whether people would pay.
Web app or mobile app for an MVP?
A responsive web app is usually the faster and cheaper way to test an idea, and it works on phones. Choose a native mobile app first only if the core loop depends on device features such as offline use, the camera in demanding ways, or background location.
What is the difference between a prototype and an MVP?
A prototype shows how a product might work, often without real data or real users, and is used to test ideas cheaply. An MVP is a working product that real users rely on for a real task, so it needs sound foundations, security and reliability — just a very small scope.
What happens after the MVP launches?
You use the evidence to decide the next release: improve the loop, add the most-requested items from the later list, change direction, or stop. The engineering team can continue against that roadmap, or hand over a documented codebase to your own team.