What to Decide Before Building an MVP

An MVP is not a smaller version of every idea on your roadmap. It is the smallest useful product that lets a defined group of people complete an important workflow and gives the team evidence for the next decision.

That word — evidence — is the one worth pausing on.

CB Insights’ analysis of why startups fail (opens in a new tab), published in March 2026, examined 431 venture-backed companies that shut down publicly since 2023. It found running out of capital in 70% of cases and poor product-market fit in 43%.

Its more useful observation is about when fit failures happen: “two-thirds of product-market fit failures were early-stage companies that never found a market.”

Money is how it ends. Not learning fast enough is often why. The same principle applies to an internal business tool: its first release should prove that one important workflow works better.

So the first release is not a demonstration of your ambition. It is an instrument for finding something out. The decisions below determine whether it can do that.

What an MVP Is Not

Three misreadings cause most of the damage, and they are worth naming before the planning starts:

• A cheaper version of the full product. Lowering quality everywhere leaves you with something nobody can judge. Cut the scope instead, and build what is left properly.
• A prototype. A prototype answers a design question and is then discarded. An MVP is real software with real users, and it has to be maintainable.
• A permanent architecture. The first release should be able to change. Decisions that are expensive to reverse deserve more thought than ones that are not.

The useful question is not “what is the least we can build?” It is “what is the least we can build that would still teach us something we would act on?”

Should You Build Custom at All?

Before scoping a custom build, it is worth asking whether you need one yet.

Custom software is the right answer when your workflow is genuinely specific, when you need to own the result, or when off-the-shelf tools cannot connect the way your business works.

It is often the wrong first answer when a no-code tool, a spreadsheet, or an existing product would let you test the same assumption this week.

A useful sequence is to validate the demand with the cheapest thing that works, then build custom once you know which parts genuinely need it.

Many successful products start as a manual process or an assembled set of tools. They become custom software only where that assembly starts to hurt.

Building custom too early spends your budget proving something a far cheaper test could have told you. Building it too late leaves you fighting tools that no longer fit.

Answer that honestly before you start scoping, not after.

Start With the User Workflow

Before discussing technology, describe who will use the product, the situation they are in, and the task they need to finish. If that is vague, the vagueness follows you into every screen and every feature.

Write the main workflow as a short sequence. For example: a customer submits a request, a team member reviews it, the system records the decision, and both sides can see the next step.

The UK Government Digital Service formalises this as a discovery phase. Its service manual (opens in a new tab) is blunt about the sequencing: “before you commit to building a service, you need to understand the problem that needs to be solved.”

It suggests around four to eight weeks as typical for that discovery, ending in an explicit decision about whether a viable service exists at all.

A short bounded investigation with a real go/no-go is cheaper than a build that discovers the same thing in month five.

Define What Belongs in Scope

Then split the must-have work from the useful-later work. Sign-in, permissions, payments, notifications, reporting, integrations, and admin tools may all matter, but the first release does not need all of them built out to the same level.

A good scope has a reason for every feature. Keep a feature in the first release when it meets at least one of these tests:

1. the first user cannot complete the core workflow without it
2. it reduces a delivery risk you have already identified
3. it gives the team control it needs from day one
4. leaving it out would force a rewrite rather than an addition

If a feature meets none of those, it is a later decision rather than a cut. Recording it that way tends to defuse the argument about removing it.

Decide How You Will Know It Worked

Before the build starts, agree what result would justify continuing, changing direction, or stopping. Without that, every outcome reads as encouraging.

Pick signals you can observe in the first weeks of real use, not ones that need a year of data:

• people complete the core workflow without being walked through it
• they come back without being prompted
• the manual work the product replaced clearly goes down
• someone asks for the next feature rather than a basic fix

Write down what you expect to see and by when. Comparing that to what happens is the whole point of releasing early.

Write Down What “Done” Means

Define what “working” means before development begins. Use observable acceptance checks such as the user can submit a request, the right person can review it, and the system records the result correctly.

The GDS guidance on writing user stories (opens in a new tab) describes acceptance criteria as “a list of outcomes that you use as a checklist to confirm that your service has done its job,” each phrased as an it’s done when… statement.

The value is that it can be checked by someone who did not build it.

At the release level, The Scrum Guide (opens in a new tab) defines the Definition of Done as “a formal description of the state of the increment when it meets the quality measures required for the product.”

Whether or not you run Scrum, the idea travels. An agreed, written quality bar stops “finished” from meaning something different to each person in the conversation.

Set Data Rules Before the Schema

Decide what information the product must store and who may access it. Privacy, permissions, retention, backups, and audit needs are easier to plan before the first database tables and integrations are in place.

For products that handle personal data of people in the EU, doing it in that order is the law, not a preference.

The European Commission’s guidance on data protection by design and by default (opens in a new tab) describes measures attaching at the earliest stages of designing the processing, with defaults set so “personal data is processed with the highest privacy protection.”

The European Data Protection Board adopted dedicated guidelines on Article 25 (opens in a new tab) in final form in October 2020 if you need the detailed regulator position.

In practice this is a short list to write down: what you collect, why, who can see it, how long you keep it, and how someone gets it deleted.

Answering those before the database is designed costs far less than adding them in later.

Choose Technology and AI Carefully

Choose technology around the product and its constraints. A modern framework can be a good fit, but the better choice depends on the users, data, integrations, delivery needs, and people who will maintain the software.

AI deserves the same discipline. Decide whether it supports the core workflow, what happens when its output is wrong, and how a person can review or correct it before treating it as a product requirement.

There is now measured reason for care. The 2025 DORA report (opens in a new tab), drawing on responses from nearly 5,000 technology professionals, reports that “AI adoption does continue to have a negative relationship with software delivery stability.”

Faster output without strong testing and review does not compound into faster delivery. It compounds into rework.

Plan Reviews, Access, Handover

Plan the review points before the first line of code. Short demos, a shared task list, and decisions written down where everyone can see them let you change course while changing course is still cheap.

The US Government Accountability Office makes the risk argument in its Agile Assessment Guide (opens in a new tab): incremental delivery with continuous evaluation “can reduce the risks of funding a program that fails or produces outdated technology.”

Agree on ownership and access from the beginning. The project should have a clear source-code repository, documented environments, an agreed deployment path, and a handover plan that does not depend on one person’s private account.

DORA’s version control capability (opens in a new tab) is specific about what belongs there: application code and dependencies, environment creation tools, container composition files, cloud configuration, and AI artefacts such as prompts.

Its stated basis is that “research consistently shows that comprehensive use of version control predicts continuous delivery.”

The GDS guidance on version control (opens in a new tab) adds the review half of the rule: “every code change is reviewed by someone who did not write it.”

Together those habits are what make a handover possible. If recreating the system depends on someone’s laptop, you do not have a deliverable — you have a dependency.

Plan the Timeline and Budget

A focused MVP can often be planned around a 6–8 week delivery window when the scope fits that shape. That is a planning reference, not a universal promise; integrations, approvals, and unknown legacy systems can change the timeline.

It helps to know how software timelines fail, because they do not fail evenly in both directions.

A study of 5,392 IT projects published in the Journal of Management Information Systems (opens in a new tab) found cost overruns follow a power law rather than a normal distribution.

Most overruns are modest, but there is “a fat tail that includes a smaller number of projects with extreme overruns.” Planning to the average understates the risk that matters.

This is not only a startup problem. The GAO’s high-risk assessment of federal IT (opens in a new tab), published in January 2025, records that federal IT investments “too frequently fail or incur cost overruns and schedule slippages while contributing little to mission-related outcomes.”

That is against annual spending above $100 billion. Scale and budget do not solve this; scope discipline and short feedback loops do.

Budget for decisions, not just coding hours. Discovery, design, building, testing, deployment, content, third-party services, and the fixes that follow launch all add to what it takes to make the first release useful.

A Worked Example

Consider a founder who wants a booking platform: customers book appointments, providers manage calendars, both sides pay and get reminders, and an admin oversees everything. It is a real product with a long feature list.

The core workflow, though, is narrow — a customer finds an available slot and books it, and the provider sees the booking. Everything else supports that or can wait.

A disciplined first release might look like this:

• In scope: provider availability, customer booking, a confirmation, and a simple provider view of upcoming bookings.
• Deferred: in-app payments (take a deposit manually at first), automated reminders, reviews, multi-provider search, and the admin dashboard.
• Decided up front: what customer data is stored and for how long, who owns the repository, and what “a booking worked” means as an acceptance check.

The deferred list is not abandoned — it is the roadmap. But shipping the core first answers the only question that matters early: will providers keep their calendars current, and will customers book?

If they will, the rest is worth building. If they will not, no amount of payment integration would have saved it.

Getting Started

The goal is not to predict everything. The goal is to make the important assumptions visible, test the core workflow, and create a product foundation that can be improved without discarding the work.

If you have an idea but not a complete specification, start with the user, the workflow, and the decision you need the first release to support. Those three points are enough to begin a useful planning conversation.