How to scope an MVP without wasting your budget

To scope an MVP without wasting budget, start from the assumption that would sink the product if it turned out to be wrong, and design the smallest thing that tests it with real users. Everything that does not help answer that question is either cut, bought off the shelf or done by hand behind the scenes. Decide how you will measure success before anything is built, so the MVP ends in a decision rather than a debate.

That sounds obvious, and most teams agree with it in principle. In practice, MVPs grow. Every stakeholder has one feature that 'customers will expect', every risk gets a mitigation, and three months later the minimum viable product is a version one that took twice as long and still has not answered the question it was meant to answer. This article is a method for stopping that, step by step.

What an MVP is, and what it isn't

Eric Ries, who popularised the term, defined the minimum viable product as the version of a product that lets a team collect the maximum amount of validated learning about customers with the least effort. In the same piece he stressed that an MVP, despite the name, is not about creating minimal products. The point is learning. A small product that teaches you nothing is not an MVP; it is just a small product.

It helps to separate four things that are often all called 'the MVP':

Much of the waste in early product budgets comes from building an MVP when a prototype or experiment would have answered the question, or building a version one when an MVP would have done.

Why scope discipline decides whether the money is wasted

Two pieces of evidence explain why scope is the main lever. First, building the wrong thing is the common failure, not building it badly. CB Insights' 2026 analysis of venture-backed shutdowns found that most ran out of capital, but described that as the final cause of death rather than the root problem; among the deeper causes, poor product-market fit was cited in 43% of cases.

Second, a large share of what gets built is not used. Pendo's analysis of usage data across software products found that 80% of features in the average product are rarely or never used, and around 12% of features generate 80% of daily usage. That data comes from mature products, not MVPs, but the lesson transfers: most of the features on an early wish list will not be the ones that matter, and you cannot reliably tell which ones will matter until people use the product.

An MVP is not a cheaper version one. It is the cheapest honest answer to the question that decides whether a version one should exist.

Step 1: write down what has to be true

Before talking about features, list the assumptions your product depends on. Marty Cagan's four big risks are a good checklist for making sure none are missed:

• Value: will customers buy it, or will users choose to use it over what they do today?
• Usability: can people work out how to use it without help?
• Feasibility: can it be built with the time, skills, data and technology available?
• Business viability: does it work for the rest of the business: pricing, sales channel, legal and regulatory constraints, support, brand?

Write each assumption as a falsifiable sentence. 'Clinics want online booking' is too vague to test. 'Receptionists at small clinics will let patients book online instead of by phone, and at least a third of bookings will move online within a month' can be proven wrong, which is what makes it useful.

Step 2: find the riskiest assumption

Rate each assumption on two scales: how badly the product fails if it is wrong, and how little evidence you have that it is right. The one that scores high on both is your riskiest assumption, and the MVP should be built around testing it. Everything else waits.

Notice that the riskiest assumption is often not technical. Founders with an engineering background tend to start with the parts they find hardest to build; founders from sales start with the pitch. The question is which assumption, if wrong, makes everything else irrelevant. Feasibility risks still matter, but they can usually be tested in parallel with a short technical spike rather than by building the whole product.

Step 3: choose the cheapest test that gives a real answer

Once you know the question, pick the cheapest method that produces a believable answer. What people say in interviews is useful for discovery but weak as proof; what they do, especially when it costs them time, money or effort, is much stronger evidence.

The UK government's service manual, which has guided a large number of public digital services, makes the same distinction. Its alpha phase is for doing the minimum you need to test your riskiest assumptions, with prototypes that are just complex enough to test ideas and not production-quality code. It also states that stopping is an acceptable outcome. That is a healthy attitude for private products too: a test that kills a weak idea early has saved most of the budget.

Step 4: cut scope down to the critical path

When the test does require real software, scope it around one journey. Pick one type of user, one job they need done, and one platform they already use. Map the steps from first contact to the moment they get value, and build only those steps. A simple story map helps: write the journey left to right, list the possible features under each step, then draw a line under the minimum that lets a user get from start to finish.

A useful discipline from the DSDM framework is MoSCoW prioritisation, which recommends that the 'must haves' take typically no more than 60% of the effort, so that there is room to absorb surprises without missing the deadline. In an MVP the must-have list should be short enough that this feels uncomfortable.

Features that are almost always safe to cut from a first MVP

• A full admin panel. Early on, the team can manage data through a database console, a spreadsheet or an internal-tool builder. Build admin screens when the people using them are not engineers.
• Fine-grained roles and permissions. One user type and one admin role is usually enough. Design the data model so permissions can be added later.
• Both mobile platforms, plus web. Choose the platform your first users are on. Our guide to native vs cross-platform development covers the trade-offs if you do need mobile.
• Multiple languages and currencies, unless your first market needs them.
• Settings and customisation. Make sensible decisions for users first; add options when people ask for them.
• Reporting dashboards. Export to a spreadsheet until you know which numbers people actually look at.
• Notifications beyond email. Push and text messages can wait until you know which events matter.
• Integrations beyond the one that the core journey depends on.

What to buy or fake instead of building

Mature services now cover most of the plumbing a product needs. Every hour spent rebuilding a commodity is an hour not spent on the part that makes your product different. The question for each capability is simple: is this where we differ from everyone else? If not, buy it.

Faking, in the Wizard of Oz sense, is the other lever. If the riskiest assumption is that customers value a recommendation, a person can produce recommendations by hand for the first fifty users while the product team learns what good looks like. For AI features in particular, this is often the fastest way to find out whether the output is worth automating. Our guide to adding AI to your product covers what comes after that test.

What not to cut

The 'viable' in MVP is not decoration. Some things are cheap to get right at the start and expensive or dangerous to add later, and cutting them does not make the experiment cleaner; it makes it invalid or risky.

• Security basics: secure authentication (bought, as above), encrypted connections, secrets kept out of the code, dependencies kept up to date, and least-privilege access to production.
• Personal data handling: collect only what you need, know where it is stored, and have a privacy notice that matches what you actually do.
• Accessibility basics: semantic markup, keyboard access, readable contrast. Retrofitting is far more work than building it in.
• Measurement: the events you need to judge success must be instrumented from day one, or the MVP ends without an answer.
• Backups and the ability to deploy a fix quickly: an MVP with real users will have bugs, and you need to ship fixes in hours, not weeks.
• The quality of the core journey. If the one thing the product does feels broken, users will reject the product, and you will wrongly conclude they rejected the idea.

Decide how you will measure before you build

Write down, before development starts, what result would make you continue, change direction or stop. Agree it with everyone who will make that decision. Without a threshold set in advance, any result can be read as encouraging, and the MVP quietly turns into a version one.

• Activation: what share of people who sign up complete the core action at least once?
• Retention: do they come back and do it again without being prompted? For most products this is the most honest signal of value.
• Willingness to pay: do they pay, pre-pay or sign a letter of intent at the price you need?
• Qualitative pull: do users ask for more, complain when it breaks, or tell colleagues?

One widely used survey measure is Sean Ellis's question, 'How would you feel if you could no longer use this product?'. Ellis found that products where around 40% of users answer 'very disappointed' tended to grow, while those below it struggled. Treat it as a guide rather than a law, and only ask it of people who have used the product enough to have an opinion.

Sample sizes will be small, and that is fine. An MVP is not a statistics exercise; it is a way to find out whether a strong signal exists. If you need a large sample to detect the effect, the effect is probably not strong enough to build a company on.

Prototype or MVP: which one do you need?

A prototype is the right tool when the riskiest assumption is about understanding or desire: will people get it, and does it solve a problem they recognise? It can be built in days, tested with a handful of people, and changed between sessions. Nielsen Norman Group has long argued that early testing with rough prototypes is worth far more than late testing with polished designs, because early findings can still change the basic approach.

An MVP is the right tool when the assumption can only be tested by behaviour over time: will people keep using it, pay for it, and change how they work? No prototype can tell you whether a receptionist will still be using a booking tool in week four. When you do move from prototype to MVP, plan to rebuild rather than extend the prototype code; the service manual quoted above recommends throwing alpha code away for good reason.

A worked example, in weeks

Back to the clinic booking product. A team that skipped the method above might plan web and mobile apps for patients, a dashboard for clinics, calendar sync with several systems, payments, reminders and reporting: easily six months of work for a team of four, before any clinic has used it.

1. Weeks 1 to 2: prototype and interviews. A clickable prototype of the clinic's booking view and the patient booking page, tested with receptionists at several clinics. Finding: receptionists fear double bookings more than anything else.
2. Weeks 2 to 3: technical spike. One engineer tests the calendar system with a documented API, proving that two-way sync is feasible and finding its limits.
3. Weeks 3 to 6: concierge pilot. Three clinics get a simple booking page; the team enters bookings into each clinic's calendar by hand and watches for conflicts. Success threshold, agreed in advance: at least a third of each clinic's bookings move online, and no receptionist asks to stop.
4. Weeks 7 to 14: the MVP. If the pilot clears the threshold, two engineers led by a senior engineer build the real product for one calendar system, web only, with bought authentication and email, no payments and no native apps.

The result is a product in real clinics in around three and a half months, with evidence behind every feature, and a clear point at week six to stop if the core assumption fails. For how these phases map to contracts, see fixed price vs time and materials. For the drivers that set the length of each phase on your own project, try the software cost calculator.

Common ways MVP budgets are wasted

• Building for scale before demand exists. Microservices, multi-region infrastructure and elaborate caching for a product with no users. A well-structured single application on a managed platform handles far more load than most MVPs will ever see.
• Polishing everything equally. The core journey deserves care; the settings page does not.
• Testing with friends. Friendly users are polite. Recruit people who match your target customer and have no reason to be kind.
• No success criteria. Without them, every result is 'promising', and the product grows without a decision.
• Treating feedback as a backlog. Users are excellent at describing problems and unreliable at designing solutions. Look for patterns, not requests.
• Letting the MVP become the product by default. Plan a deliberate review point where you decide what to keep, rebuild or throw away.

If you are building a subscription product, our SaaS development guide covers what changes once the MVP has proven its value and you need billing, multi-tenancy and onboarding that works without you in the room.

How Authect approaches this

When we scope an MVP, the conversation starts with assumptions, not features, and the founders who run that conversation are the engineers who build the product. That matters in scoping, because the trade-offs between what to build, buy or fake are technical judgements as much as product ones. Every project is led by a senior engineer, and we use AI to move faster on the parts that do not need to be invented, with an engineer reviewing every line.

Early-stage work usually starts as a fixed-price discovery or prototype, followed by monthly sprints once there is something real to learn from. You own the code, designs and infrastructure from the first day, so if the evidence says stop, you stop with everything you paid for. If you have an idea and a long feature list, talk to the founders and we will help you find the shortest route to an honest answer.