How to build an MVP in 2026: scope, cost and process

In this guide

This is the hub for everything on the blog about building a first version. Each section below is a summary, with a link down to the full article on that step.

• What an MVP is for. The point of the first version, and how it differs from a prototype.
• Testing the idea first. Four cheap tests before anyone writes code.
• One user, one job. The sentence that decides the scope.
• Cutting features. How to get a long list down to what the first user needs.
• SaaS, marketplace or AI tool. What changes with the kind of product.
• Choosing a build route. Doing it yourself, AI builders, no-code, a freelancer or an agency.
• Hiring well. What to ask, and fixed price versus day rate.
• Cost. What moves the number, with UK figures.
• Timelines. Where the weeks go.
• The build, week by week. How a well run build actually unfolds.
• The stack. Boring choices that keep the next developer happy.
• Launch and after. What has to be true before real users arrive.

If you only have two minutes, open the MVP cost calculator for a rough UK price, and the MVP scoping tool to turn a feature list into a must-have list.

What an MVP is for

An MVP is the smallest version of a product that lets you learn whether real people want it, ideally by watching them use it and pay for it. It is a learning tool that happens to be software. It is not a cheap version of the product you imagine in three years.

That definition has consequences. If the question you need answered is "will people sign up for this", a landing page and a waitlist may be enough. If it is "will people pay for this every month", you need something they can actually use and a way to charge them. If it is "can you fill both sides of this marketplace", you need enough of the product for both sides to do the core transaction, even if half of it runs by hand behind the scenes.

A prototype is a different thing. A prototype shows how the product would work: clickable screens in Figma, or a demo built in an AI tool. It is good for testing whether people understand the idea and for showing investors. It usually is not safe to put real customer data or real payments through. I have written up the difference between a prototype and an MVP in more detail, because mixing the two up is behind a lot of wasted budgets.

If it helps to see what the first version of a real product looked like, the MVP examples article walks through well known first releases and what each one left out.

Test the idea before the build

The cheapest MVP is the one you do not have to build yet. Before paying for code, it is worth spending a week or two finding out whether the riskiest part of the idea holds up. Four tests I suggest to almost every founder:

• Talk to ten of the people in your one-sentence user. Not about your idea: about how they deal with the problem today, what it costs them, and what they have already tried. If nobody has tried anything, the problem may not hurt enough.
• Put up a landing page with one clear promise and one action. A waitlist, a pre-order or a "book a demo" button. The number that matters is not visits but how many of the right people take the action.
• Do the job by hand. Run the service yourself for three to five customers, using email, a spreadsheet and a Stripe Payment Link. If you cannot get five people to accept the manual version, software will not fix that.
• Show a clickable prototype. Put Figma screens or an AI-built demo in front of real users and watch where they get stuck. Changing a screen at this stage costs minutes.

These tests do not prove the product will work. They catch the ideas that clearly will not, and they sharpen the ones that might. They also give you something concrete to scope from: the words people used, the step they got stuck on, the feature nobody mentioned.

This is what my Validation Sprint is for. In 1 to 2 weeks, from £3,500, you get the user flows, a clickable prototype to test with real people, a build plan and a fixed quote for the build. If the test changes the plan, it changes before any money goes on code.

Start with one user and one job

I start every scope with the same sentence:

For [a specific person], [the product] does [one job], so they can [an outcome they care about].

"For street food traders, FindPopups shows where markets and pop-ups are on, so they can plan where to trade next" is a usable sentence. "For small businesses, an all-in-one platform to manage their operations" is not, because it does not tell you which screen to build first.

The sentence does three things for you:

1. It names the first user. Not every user. The one you will put the product in front of first, and the one whose feedback decides version two.
2. It names the job. One job. If you find yourself writing "and", you probably have two products.
3. It gives you a test for every feature. Does this feature help that person do that job? If not, it waits.

Once you have the sentence, map the main flow: the steps the first user takes from arriving to getting the job done. Keep it on one page. A good first flow has somewhere between five and twelve steps. If it has thirty, the product is too big for a first version, or the flow is doing work that a person could do by hand.

Then write the scope down. A short document is enough: the sentence, the flow, the screens, the list of features with a must, should or later against each, and what is explicitly out. I have a product spec template you can copy, and a fuller walk through of how to scope an MVP step by step.

Cut the feature list

Most founders arrive with a feature list two or three times longer than their first version needs. That is normal. The list is a record of everything you have thought about, not a plan.

The quickest filter I know is three questions per feature, which is how the MVP scoping tool works:

• Does the first user need it to get value? If they can do the core job without it, it is not a must-have.
• Does it block you taking payment? If you are testing whether people will pay, anything between them and paying you is a must-have.
• Could you do it by hand at first? Sending invoices from Stripe, approving accounts yourself, matching people over email. Slower per user, much faster to launch.

Features that usually survive the cut: sign-in, the core flow, a basic settings page, a way to pay or to register interest, transactional emails, and the admin view you need to support users. Features that usually do not: team accounts and roles, in-app chat, detailed analytics dashboards for users, a mobile app on top of the web app, integrations with tools nobody has asked for yet, and anything described as "AI-driven insights" that has not been tested by hand first.

There is a longer list, with the reasoning behind each, in MVP features to cut. For subscription software specifically, the features a SaaS MVP actually needs covers billing, onboarding and the admin side.

SaaS, marketplace or AI tool

The process is the same for every kind of product, but the shape of the work is not. Three types cover most first versions.

Subscription software

One type of user, one core workflow, recurring billing. This is the most predictable kind of MVP to scope. The work that gets underestimated is around the edges: what happens when a card fails, when someone cancels, when a team wants a second seat, when a trial ends. You do not need all of it on day one, but you need to decide which you are handling by hand. See SaaS MVP features for the list.

Marketplaces

A marketplace is two or three products sharing a database: one for each side, plus the admin view only you see. Every feature has to be thought through from both sides, money between strangers is harder than money from a customer, and the product is useless until both sides have something in it. I have a full guide to building and pricing a marketplace MVP, using FindPopups, a marketplace I designed and built for a client, as the worked example.

AI products

If the product wraps an AI model, the riskiest question is usually not the interface. It is whether the model does the job reliably enough, often enough, at a cost per use that leaves you a margin. Test that before building the product around it: run the prompts by hand against real inputs, look at the failures, and price the calls. The build then adds the parts people underestimate, such as streaming responses, retries, rate limits, logging what the model said, and a way for users to correct it. Building an AI app MVP goes through it step by step.

Choose a build route

There are five realistic ways to get a first version built. None is right for everyone, and the honest answer depends on what you are testing, your budget, and how much of your own time you have.

Doing it yourself with AI builders. Lovable, Bolt, v0, Replit and Cursor have made it possible for a non-developer to produce a working demo in an afternoon. For a prototype, a pitch or an internal tool, that is genuinely good value. The difficulty comes later: authentication that does not hold up, database rules that let one user see another's data, payments that are not wired to webhooks, and code nobody fully understands. If you go this way, plan for a review before real users and real money go through it. The fix pillar covers what tends to break.

No-code platforms. Bubble, Glide, Softr and similar tools are fast for a certain kind of product, usually forms, lists and workflows. The trade-off is lock-in: you are building on someone else's platform, with their pricing and their limits. I compare the two approaches in no-code versus code for an MVP.

A freelancer. One person, usually cheaper than an agency, and quality depends entirely on who you find. The risk is the gap between design and build: many freelancers are strong at one and acceptable at the other.

An agency. A team, a process and a project manager. More expensive, often slower to start, and sometimes a senior team in the pitch and a junior team on the work. Right for bigger builds and for founders who want to be managed rather than to manage. Agency, freelancer or AI sets the three side by side, and UK versus offshore covers the location question.

A designer who codes. One person who scopes, designs and builds. Fewer handoffs, and the design decisions and build decisions get made together. This is what I do, so read my view on it with that in mind. The case for and against is on the designer who codes page.

The full decision, including when it makes sense to build it yourself even if you can afford not to, is in build your MVP yourself or hire.

Hire someone well

If you hire, most of the risk sits in two decisions: who you pick and how you agree to pay them.

On who, look for evidence rather than adjectives. A live product they built, that you can sign up to and use on your phone, tells you more than a portfolio of screenshots. Ask them to walk you through how they would scope your first version, and listen for whether they cut things or add things. Ask where your data will live, who can see it, and how they handle sign-in. Ask who owns the code, the hosting account and the domain on day one. The answer to all three should be you.

Questions worth asking on the first call:

On how to pay, there are two common models. A day rate means you pay for time, so changes are easy but the total is open-ended. A fixed price means you pay for an agreed scope, so the total is known but changes go through a change request. Fixed price works when the scope is written down; day rate works when it genuinely cannot be. I explain the trade-offs in fixed price versus day rate, and the full hiring process, including red flags, in hiring an MVP developer.

What it costs

Most MVP quotes are a day rate multiplied by a guess at the number of days. The day rate depends on who you hire. The number of days depends on the scope, and on how much of it is still undecided when work starts.

For a sense of the day rate side, ITJobsWatch puts the median UK contract rate for a software developer at £529 a day over the six months to 10 November 2026, with the 10th to 90th percentile running from £364 to £638. A focused web MVP from one developer working 30 to 40 days at that median is roughly £16,000 to £21,000 before any design work. That is arithmetic, not a quote, but it is a useful sanity check against any number you are given.

The things that move the number most:

• Types of user. Each one needs its own sign-up, screens and permissions.
• Money. A Stripe Payment Link takes payment without any code. Split payments, refunds and payouts between two parties are a different job.
• Integrations. Every outside service adds setup, error handling and testing.
• Platform. A web app that works on a phone is one codebase. Native iOS and Android is two, plus app store reviews.
• Undecided scope. Screens designed during the build get designed at build rates, often twice.

My own prices, so you have a fixed reference point: a Validation Sprint starts at £3,500 and takes 1 to 2 weeks, ending in user flows, a clickable prototype, a build plan and a fixed quote. An MVP Build starts at £12,000 and typically goes live in 4 to 6 weeks, depending on scope. Build Club is £4,500 a month for ongoing work after launch. A build with more user types or harder payments sits above the starting price, and you see the exact number in writing before paying anything.

For published UK agency ranges by type of product, and what pushes a build up or down a band, read how much an MVP costs in the UK. For a rough number based on your own answers, the MVP cost calculator takes about two minutes and needs no sign-up.

How long it takes

Ask five builders how long an MVP takes and you will get five answers, and marketplaces and products with several user types always sit at the long end. The spread is not about how fast people type. It is about what happens around the typing.

Where the weeks actually go:

• Decisions. Every unanswered question in the scope becomes a pause in the build. A founder who replies within a day keeps a build moving; one who replies within a week can double its length.
• Design. If the screens are not designed before the build, they get designed during it. That is slower and usually means building some things twice.
• Integrations. Third-party services rarely behave exactly as their docs suggest on the first try. Payments, email deliverability and anything involving a calendar are the usual suspects.
• Testing on real devices. Things that look fine on a laptop break on an older phone or a slow connection.
• Launch admin. Domains, email sending records, Stripe account verification, privacy policy, cookie consent. Small jobs that add up to days.

My MVP Builds usually go live in 4 to 6 weeks, because the scope is fixed before the build starts and design and code are done by the same person, with AI tools taking care of a lot of the repetitive code. The full breakdown, with a realistic timeline for each kind of product, is in how long it takes to build an MVP.

The build, week by week

Whoever builds it, a well run MVP build has a recognisable shape. This is how mine run, and it is a good template to hold anyone else to.

1. 1

   Before week one: scope and price

   The one-sentence user and job, the main flow, the screen list, the must-have features and the out-of-scope list, with one price against it. If this is still loose, it is a Validation Sprint first.

2. 2

   Week one: flows and key screens

   The main flow designed end to end, plus sign-in, the empty state and the settings page. The data model gets decided now too, because it is expensive to change later.

3. 3

   Weeks two and three: the core flow, working

   Sign-in, the database, the main flow working with real data, deployed to a preview link you can open on your phone. Feedback goes in every week, not at the end.

4. 4

   Week four: payments, email and admin

   Stripe wired up with webhooks, transactional emails sending from your domain, and the admin view you need to support the first users.

5. 5

   Weeks five and six: edge cases, polish and launch

   Error, empty and loading states, mobile checks, accessibility basics, analytics, then live on your domain with the accounts in your name.

Two habits make the biggest difference. First, a preview link from the end of week one, so you are reacting to working software, not descriptions of it. Second, a written list of decisions as they are made, so nobody has to remember why something was built the way it was.

The thing to avoid is the reveal: weeks of silence followed by a big demo. By the time you see it, every misunderstanding has been built in.

The stack

For most web MVPs, the right technology is the boring, well supported choice that the next developer you hire will already know. Exotic stacks make the first build feel clever and the second developer expensive.

What I use, and would recommend to most founders building a web product:

• Next.js, React and TypeScript for the front end and much of the back end. Huge community, well documented, easy to hire for.
• Postgres for the database. Relational, reliable, and available from every major host.
• Stripe for payments, from Payment Links at the simplest end to full subscriptions and Connect for marketplaces.
• Vercel for hosting, with preview deployments for every change.
• Shopify when the product is really a shop. Building your own checkout for a store is rarely worth it.

What matters more than the specific tools:

• You own the accounts. GitHub, hosting, database, Stripe, domain and email, all in your name or your company's, from day one.
• The code is readable. Someone else should be able to pick it up from the repository and a short README.
• The data model is deliberate. Expensive rewrites very often trace back to a database designed in a hurry.

If you already have a prototype built with an AI tool, you do not necessarily need to throw it away. Sometimes the right move is to harden it, sometimes to rebuild the parts that matter and keep the design. The launch pillar covers that path, from exporting the code to adding Stripe properly.

Launch and what comes after

An MVP is launched when real people outside your circle can sign up, use it and, if relevant, pay, without you standing behind them. Before that point, check the things that cause the most painful first weeks:

The full list is in the app launch checklist, and the UK data protection side is covered in GDPR for startups in the UK.

After launch, the job changes. You are no longer building to a plan; you are learning from what people do. Set up analytics for the main flow before you launch, talk to the first users directly, and keep a short list of what you will build next, ranked by evidence rather than by the loudest request. Getting the first 100 users is usually manual work, and that is fine.

Budget for this phase. Something will break in the first month, someone will ask for a feature that turns out to matter, and the scope you cut will start coming back as real requests. That is the MVP working.

Where to start

If you are at the idea stage, write the one-sentence user and job, then list every feature you can think of and run them through the MVP scoping tool. Take the must-have list into the MVP cost calculator for a rough UK price. Those two steps take about ten minutes and will make every conversation with a developer, freelancer or agency shorter and more useful.

If you already know what you want to build and want it designed and built by one person, the packages are on the pricing section of the home page, and you can book a call to talk it through.

The articles in this pillar, in the order most founders need them:

• How to scope an MVP
• MVP features to cut
• SaaS MVP features
• Marketplace MVP: scope and cost
• How to build an AI app MVP
• MVP examples from real products
• Build your MVP yourself or hire
• Hiring an MVP developer
• Fixed price versus day rate
• How much an MVP costs in the UK
• How long it takes to build an MVP