Strategy • Engineering • Fundraising

How to Scope an MVP Without Wasting Your Seed Round

Most seed-stage founders either build too much or too little. Both mistakes burn through your runway and leave you with nothing to show investors. Here is a practical framework for getting MVP scope right.

Mike Tempest • 11 min read • 29 March 2026

There are two ways to waste a seed round on your MVP. The first is overbuilding: spending 60% of your funding on a V1 that has every feature you can imagine, takes nine months to ship, and leaves you with barely enough runway to learn whether anyone actually wants it. The second is underbuilding: shipping something so thin, so stripped back, that nobody can tell what your product actually does or why they should care.

Both mistakes come from the same place. Founders who overbuild are afraid of launching something imperfect. Founders who underbuild have read too many blog posts about "lean startup" and confused a landing page with a product. Neither approach tests the thing that actually matters: whether your core assumption about the business is correct.

After helping multiple startups scope and ship their first products, from fintech platforms at Risika to consumer apps at RefME, the pattern is clear. The founders who get MVP scope right are not the ones with the best ideas. They are the ones who are honest about what they do not know and disciplined about testing one thing at a time.

What an MVP Actually Is (and Is Not)

The term "minimum viable product" has been so thoroughly abused that it has lost most of its meaning. So let us be precise about what it is.

An MVP is the smallest thing you can build that tests your riskiest assumption. That is it. Not a prototype. Not a beta. Not your full vision with fewer features. It is a focused experiment designed to answer a specific question about whether your business will work.

A prototype proves that something is technically possible. An MVP proves that someone will use it, pay for it, or change their behaviour because of it. A beta is a nearly finished product being tested for bugs. An MVP might be rough around the edges because polish is not the point. The point is learning.

The word "viable" is doing most of the work in that phrase. Your MVP needs to be good enough that real users can actually use it and give you meaningful feedback. A landing page with an email signup is not an MVP. A clickable Figma prototype is not an MVP. These are useful tools for earlier stages of validation, but they are not products that test whether your business works.

Equally, "minimum" means minimum. If your MVP has user roles, an admin dashboard, email notifications, third-party integrations, and a settings page, you have not built an MVP. You have built a product. And you have probably spent too much money doing it.

The Assumption Stack

Every startup is built on a stack of assumptions. Your MVP should test the scariest one first.

Before you write a single line of code, write down every assumption your business depends on. Then sort them into three categories.

Market Assumptions

These are assumptions about whether anyone cares. Does this problem exist? Is it painful enough that people will pay to solve it? Is the market big enough? Can you reach your target customers?

Example: "HR managers at companies with 50 to 200 employees spend more than 10 hours per week on manual onboarding tasks and would pay £500 per month to automate them."

Business Model Assumptions

These are assumptions about whether the economics work. Will people pay your price? Can you acquire customers cheaply enough? Will they stick around long enough to be profitable? Can you deliver the service at a cost that leaves margin?

Example: "Restaurants will pay a 15% commission on orders placed through our platform, and the average order value will be high enough to cover delivery costs."

Technical Assumptions

These are assumptions about whether you can actually build it. Can the technology work at the required speed, accuracy, or scale? Can you access the data you need? Are there regulatory or technical constraints that make this impossible?

Example: "We can process and categorise bank transactions in real time with 95% accuracy using machine learning."

Now rank them. Which assumption, if wrong, kills the business entirely? That is the one your MVP needs to test. For most startups, the riskiest assumption is a market assumption, not a technical one. The technology usually works. The question is whether anyone cares.

If your riskiest assumption is "will people pay for this?", your MVP needs to get to the point where someone hands you money. Not where they say they would pay. Where they actually do. If your riskiest assumption is "can we process this data accurately enough?", your MVP needs to prove the technology works on real data. Everything else is secondary.

The 3-Month Rule

Here is a simple rule: if your MVP takes longer than three months to build, you have scoped it wrong.

This is not an arbitrary number. Three months gives you enough time to build something meaningful, but not so much time that you burn through your runway before learning anything. It forces discipline. It makes you choose what actually matters.

When founders tell me their MVP will take six months, I ask them to split it in half. When they say that is impossible, we sit down and go through the feature list. Every single time, we find that half the features are nice-to-haves disguised as must-haves.

Here is how real startups have descoped effectively:

The marketplace that launched with one side

A two-sided marketplace planned to build both the supplier portal and the buyer experience simultaneously. Six-month estimate. Instead, they launched with just the buyer side, manually onboarding suppliers via spreadsheets and phone calls. Shipped in 10 weeks. Learned that buyers wanted something completely different from what they had assumed, which would have meant rebuilding the supplier portal anyway.

The fintech that skipped the dashboard

A financial analytics platform planned a beautiful dashboard with charts, filters, and export functionality. Four-month build. Instead, they shipped the core analysis engine and emailed results as PDF reports. Shipped in 8 weeks. Discovered that their customers cared about the accuracy of the analysis, not the presentation. The dashboard came later, informed by what customers actually needed to see.

The SaaS that started with a single workflow

An HR tool planned to handle onboarding, offboarding, leave management, and performance reviews. Seven-month roadmap. They launched with onboarding only, covering one workflow end to end. Shipped in 11 weeks. Onboarding alone was valuable enough that customers signed up and paid. The other features followed quarter by quarter.

The pattern is the same every time. The original scope felt essential. When forced to cut, founders discovered that a smaller version was not just buildable but often better, because it forced clarity about what the product actually was.

What to Cut and What to Keep

Not all features are equal. Some can be brutally simplified for your MVP. Others cannot be touched without undermining the entire point of the exercise.

Safe to Simplify

+ Authentication: Email and password is fine. SSO, social login, and MFA can wait.
+ Admin panels: You can manage things via direct database queries or simple scripts for the first few months.
+ Integrations: CSV import and export covers most early needs. API integrations can come later.
+ Notifications: A simple email is enough. Push notifications, in-app alerts, and digest emails are features, not foundations.
+ Billing: Stripe Checkout or even manual invoicing. You do not need a subscription management system for your first 50 customers.
+ Reporting: Spreadsheet exports or scheduled email reports. A reporting dashboard is a product in itself.

Do Not Cut

- Core user experience: The main workflow your users will go through needs to feel right. This is where first impressions are made.
- Data model: Get your data architecture right from the start. Migrating a bad data model later is expensive and painful.
- Your differentiator: Whatever makes your product different from the alternatives needs to be present and working. That is the whole point.
- Security basics: HTTPS, password hashing, input validation. Do not ship something insecure because "it is just an MVP".
- Performance on the critical path: If your core feature is slow or unreliable, users will not come back regardless of how many other features you have.

The principle is straightforward. Anything that supports the core experience can be manual, ugly, or missing entirely. But the core experience itself, the thing you are testing, needs to work well enough that you get honest feedback about whether the idea has legs.

The Runway Calculation Founders Skip

Most founders know roughly how much money they have. Surprisingly few have done the maths on how much their MVP should cost relative to their total runway. Here is the calculation you should be doing before you write a brief or hire a developer.

Let us say you raised a £1.5M seed round. Here is how you should think about allocating it:

Total seed round £1,500,000

MVP build (15-20%) £225,000 to £300,000

Post-MVP iteration and learning (20-25%) £300,000 to £375,000

Team and operations (30-35%) £450,000 to £525,000

Buffer and runway to next milestone (20-25%) £300,000 to £375,000

The critical insight is that the MVP build is the smallest allocation. Most of your seed round should go towards what happens after you ship. The iteration phase, where you learn from real users and adjust, is where the real value is created.

Founders who spend £600K or £800K on their first build are not just overspending on the MVP. They are stealing from the iteration budget, which is where startups actually find product-market fit. They are also compressing their runway, which means they hit their next fundraise with less traction and less time to demonstrate progress.

The maths gets worse when you factor in time. If your MVP takes six months instead of three, that is not just more development cost. It is six months of salaries, office costs, and burn rate before you have learned anything. A founder spending £40K per month on overhead who takes six months to ship has burned £240K on operations alone before a single user has seen the product.

Do this calculation before you scope your MVP, not after. Work backwards from your runway. How many months do you need to get to your next milestone, whether that is Series A, profitability, or a key partnership? How much will that cost in team and operations? Whatever is left after that is your development budget. If it is not enough to build what you have planned, you have not scoped wrong. You have planned wrong.

When to Bring in Technical Leadership

If you are a non-technical founder scoping an MVP, you have a problem. You need to make decisions about technology, architecture, and scope, but you do not have the expertise to evaluate whether the advice you are getting is any good.

This is where most founders make one of three mistakes.

Mistake one: letting the dev agency scope the build. Agencies are incentivised to build more, not less. Their revenue is tied to the size of the project. An agency quoting your MVP is like asking a builder how big your extension should be. They will always find reasons to add another room. This does not make them dishonest. It makes their incentives misaligned with yours.

Mistake two: relying on a developer friend to estimate. Your mate who codes is probably a good developer. But estimating MVP scope is not a development skill. It is a product and business skill that requires experience shipping products, understanding what can be deferred, and knowing where technical shortcuts create problems later versus where they are perfectly fine. Most developers estimate optimistically because they are thinking about the happy path, not the edge cases, the deployment pipeline, or the data migration.

Mistake three: scoping it yourself from blog posts and competitor analysis. You end up with a feature list based on what other products have, not on what you need to test. Competitors have features because they have been iterating for years, not because those features were in their MVP.

What you actually need is someone who has shipped MVPs before and knows what can be cut. Someone who understands both the technical constraints and the business context. Someone whose incentives are aligned with yours, meaning they succeed when you spend less, learn faster, and ship something that actually tests your core assumption.

A Fractional CPTO or technical advisor can fill this gap. Not as someone who writes code, but as someone who helps you make the right decisions about what to build, what to skip, and how to structure the work so you do not paint yourself into a corner. The cost of a few days of senior technical input at the scoping stage is trivial compared to the cost of building the wrong thing for six months.

The Bottom Line

Scoping an MVP well is not about being clever. It is about being honest. Honest about what you do not know. Honest about what your riskiest assumption is. Honest about how much money you have and how far it needs to stretch.

Identify your riskiest assumption. Build the smallest thing that tests it. Ship it in three months or less. Spend no more than 20% of your runway on the first build. Keep the rest for iteration, team, and buffer. Cut everything that does not serve the core test, but do not cut the core test itself.

The founders who get this right are the ones who arrive at their next milestone with data, traction, and runway. The ones who get it wrong arrive with a polished product that nobody uses and six months of runway left.

Your seed round is a finite resource. Every pound you spend on features that do not test your core assumption is a pound you cannot spend on finding product-market fit. Scope accordingly.

StrategyEngineering

Need help scoping your MVP?

Get senior technical input on your MVP scope from a Fractional CPTO who has shipped products from zero to millions of users. Honest advice on what to build, what to skip, and how to protect your runway.

Book a Free Day Get in Touch

Frequently Asked Questions

How long should it take to build an MVP?

A well-scoped MVP should take no longer than three months to build. If your timeline is longer than that, you have almost certainly scoped too much. The goal is to test your riskiest assumption as quickly as possible, not to build a complete product. Break the scope down further until you can ship something meaningful in 12 weeks or less.

How much of my seed round should I spend on the MVP?

As a general rule, your MVP should consume no more than 15 to 20 percent of your total seed funding. If you raised £1.5M, that means roughly £225K to £300K on your initial build. The rest needs to cover iteration based on what you learn, team growth, operations, and enough runway to reach your next milestone, whether that is Series A or profitability.

What is the difference between an MVP and a prototype?

A prototype demonstrates a concept. An MVP tests a business assumption with real users. Prototypes can be throwaway code, clickable mockups, or even paper sketches. An MVP needs to be good enough that real users will actually use it, pay for it, or engage with it in a way that generates meaningful data about your riskiest assumption.

Should I use a dev agency or hire engineers to build my MVP?

It depends on your situation, but agencies can work well for MVPs if you have clear scope and strong technical oversight. The danger is that agencies are incentivised to build what you ask for, not to challenge your scope. Without someone technical on your side asking hard questions about what can be cut, agency builds tend to run over budget and over time.

What features should I cut from my MVP?

Cut anything that does not directly test your riskiest assumption. Admin panels can be manual database queries. Authentication can be simple email and password. Integrations with third-party tools can wait. Reporting can be spreadsheet exports. But do not cut your core user experience, your data model, or the thing that makes your product different. Those are the whole point of the MVP.

Mike Tempest

Fractional CPTO

Mike is a Fractional CPTO helping UK startups build the right thing, not everything. With experience scaling products from zero to millions of users at Risika and RefME, he brings commercial thinking to technical decisions. Book a free day at fcto.uk/free-day.

Learn more about Mike