Guide · Starting out

How to build an MVP step by step: the 8 steps from idea to first paying users

How to build an MVP step by step: the riskiest assumption, what to cut, who builds it, weekly slices, launch and what comes next. Plus AI tools and YC advice.

By Akash Bansal, founding engineerUpdated 5 November 20268 min read

Most step-by-step MVP guides start at "define your features". That's step four. The steps before it are the ones that decide whether you build the right small thing or a polished version of the wrong one. Here's the process I take founders through before a line of code gets written, and what happens after.

I've already written up what an MVP costs and how long it takes, week by week, so this post links to those rather than repeating them. This one is about the order of decisions.

How do you build an MVP step by step?

You build an MVP in eight steps: name the riskiest assumption, test it without code, cut the product to one workflow, choose who builds it, write the scope down, build in weekly slices, launch to a small group, then decide from what they do. Steps one to three are cheap and decide most of the outcome.

Step 1: What is your riskiest assumption?

It's the one belief that, if wrong, makes everything else pointless. Write it as a sentence you could prove false. "Clinic owners will pay $99 a month to stop double-bookings" can be tested. "People need better scheduling" can't.

This is what an MVP is for. Eric Ries defined it as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort (Lean Startup Co.). The word that matters is learning. If you can't say what the MVP is meant to teach you, you're not building an MVP, you're building version one of a guess.

Common riskiest assumptions, roughly in the order I see them:

• Demand: enough people have this problem badly enough to change what they do.
• Willingness to pay: they'll pay, and at a price that works.
• Reach: you can get in front of them without a huge ad budget.
• Supply (marketplaces): the other side will show up too.
• Feasibility: the hard technical part works at all. This one is rarer than founders think; most ideas are buildable.

Step 2: Can you test it before writing code?

Usually, yes, and you should. Interviews about how people solve the problem today, a landing page with a price on it, a pre-sale, or a version you run by hand behind a simple form will test demand and willingness to pay for close to nothing. I wrote a full guide to these methods: how to validate a startup idea before building.

Move to step three when you have a signal that cost someone something: time on a call, an email address next to a price, a deposit, a signed pilot. Compliments don't count.

Step 3: Which features belong in the MVP?

Only the ones needed for one type of user to complete one core job, end to end. Everything else goes on a "later" list, which you keep, so cutting doesn't feel like losing. Here's a cut I'd make on a typical booking-style idea.

If you're building a two-sided product, the cut is harder and different; I covered it in what to cut from a marketplace MVP.

Step 4: Who should build your MVP?

The cheapest option that can make the cut version safe for real users and real money. Here's how I'd match the builder to the job.

I compared these options in depth in technical cofounder vs founding engineer vs agency, and covered how to actually find each one in how to find a developer for your startup.

Step 5: What should the written scope include?

One or two pages that anyone could build from and anyone could check against. Mine always cover:

1. Who the first user is, in one paragraph.
2. The one job version one does for them.
3. What's explicitly out (the later list).
4. The main screens, and what happens on each.
5. The data model: what's stored and who can see it.
6. Outside services: payments, email, maps, AI models.
7. A week-by-week plan, with what you'll be able to click at the end of each week.
8. How you'll know it's done: the acceptance checks.

On my builds this is the output of the scoping step, and the price is fixed against it. A written scope also protects you: when someone says "while you're in there, could you also…", you can both see that it's new, and swap something out for it.

Step 6: How should the build run?

In weekly slices, each ending in something you can click yourself. Not a status report, the actual product, a little further along. If week three's demo doesn't show the core workflow working, you find out in week three, while there's still time to cut. I laid out what each week contains in the week-by-week MVP timeline.

Your job during the build is to turn up. Block an hour after each demo for feedback and decisions. Feedback that waits a week adds a week. And keep the code, cloud accounts and domain in your name from day one; the checklist for that is in who owns the code.

Step 7: How do you launch an MVP?

Quietly, to a small group you can talk to. Five to twenty users who have the problem is enough to learn from. Launch here doesn't mean a press day; it means real people using it for the real job. Michael Seibel's Startup School advice is to "launch something bad quickly", and he says an MVP should be buildable "in weeks, not months" (Y Combinator).

Before launch, decide what you'll measure. A short list beats a dashboard:

Step 8: What do you do after the MVP launches?

You decide between three moves, based on what users did: keep improving the same product for the same user, change course, or start scaling what works. Seibel's version: iterate on the user's problem rather than chasing unrelated uses, and don't fall in love with the MVP, because it's just step one.

• Iterate when people complete the core job and some come back, but they get stuck or ask for the same missing piece.
• Change course when they sign up and never finish the job, or finish it once and never return, even after you've fixed the obvious problems.
• Scale when people come back without being chased and pay at your price. Now the "later" list and the work to make it sturdier earn their place.

Decide in advance who handles the weeks after launch: the person who built it on a retainer, your first in-house engineer working from the handover docs, or a second fixed-scope phase. Bugs real users find are a sign the MVP is working, not failing.

How do you build an MVP with AI tools?

Use them hardest in steps two and three, and carefully in step six. AI app builders and coding assistants make a clickable prototype or a narrow working tool very fast, which is perfect for testing demand. They also help draft interview questions and summarise what users told you.

They don't decide what to cut, and they don't notice what they got wrong. Security gaps, data one user can see that they shouldn't, payments that fail on the edge cases: those need a person who reads the code. A sensible split is to prototype with AI, learn from real users, and bring in an engineer for the version that holds real data and real money. If you're already at the point where the prototype is fighting you, see rescue, rebuild or keep prompting.

What does building an MVP cost?

A focused MVP with one senior engineer runs roughly 6–10 weeks, and my builds start at $15,000 for that scope. Second user types, native mobile apps and complex integrations push it up. Once your scope from step three is written down, the app cost calculator turns it into a rough range. The full line-item breakdown, and when you shouldn't spend that money yet, is in what an MVP app costs in 2026.

A checklist before you start building

• Your riskiest assumption, written as a sentence that could be proved false.
• At least one signal that cost someone something: a deposit, a pilot, a waitlist with a price on the page.
• A cut list: keep, later, never.
• A builder who matches the stage, not the dream.
• A one- or two-page scope with weekly demos and acceptance checks.
• Accounts in your name: domain, repository, cloud, payments.
• Three metrics you'll check in the first month.

If you've done steps one to three and need someone to take steps four to seven end to end, that's the build I do: a written scope, one fixed price, a demo every week and everything in your name. Here's how I work.