Building an MVP: A Step by Step Guide for Startups That Ships

Building an MVP: a step by step guide for startups that actually ships something

A founder emailed me last month with a screenshot of his Stripe dashboard. Eleven pre-orders, €1,870 collected, and a product that didn't exist yet beyond a Figma file and a landing page. "Is this an MVP?" he asked. My answer: it's better than one. He'd already validated demand without writing a single line of code, which is the entire point of building an MVP — and the part most startup guides rush past because it doesn't sound technical enough.

I've watched teams burn fourteen months and six figures building "MVPs" that nobody wanted. I've also watched a two-person team validate a B2B tool in nine days for under €3,000. The difference was never engineering talent. It was deciding what not to build.

What is the MVP stage of a startup, really?

Strip away the jargon and an MVP is a test with a deadline. You believe something about your market — that a specific group of people will pay for a specific solution to a specific problem. The MVP is the cheapest possible experiment that proves or destroys that belief.

The difference between an MVP and a "minimum lovable product"

I'll take a side here: the "minimum lovable product" framing has cost more founders more money than almost any other piece of startup advice. It sounds good in a conference talk. In practice, it pushes teams to polish design and add delightful details before they know anyone wants the thing.

The catch? "Lovable" is a moving target set by you, not your users. "Viable" is set by the market, and the market doesn't care about your onboarding animation.

MVP in software, web development, and project management

The term travels across disciplines, which is why definitions get muddy. In software, an MVP is a shippable build with one core loop working end to end. In web development, it's often just a landing page plus a manual backend — I've used an Airtable base and a Zapier chain as the entire "backend" for a paying product. In project management, MVP means the smallest scope that still delivers measurable value, which is close to the startup meaning but with less existential risk attached.

Wherever you meet the acronym, the test is the same: what assumption does this remove? If you can't answer that in one sentence, you're building a product, not an MVP.

How do startups build an MVP? The 7 stages, in order

Most guides list steps without naming them. Here's the sequence I actually follow, and I'll flag where teams usually go wrong.

Stage 1: idea and the one assumption that matters

Write down everything you believe about your market. Then circle the single belief that, if false, kills the whole business. For a scheduling tool aimed at dentists, that's probably "dentists will pay €40 a month to stop phone-tag with patients." It is not "dentists want a nice calendar UI."

Stage 2: user research that isn't an echo chamber

Talk to ten people who match your buyer. Not friends. Not your old colleagues. Ten actual strangers who have the problem. If you can't find ten, that's your first data point, and it's not a good one.

Stage 3: define the MVP scope in writing

One page. What it does, what it explicitly does not do, and how you'll know it worked. The "how you'll know" line is non-negotiable. Mine usually reads something like: "Ten users complete the core action twice within two weeks."

Stage 4: prototype before you code

A clickable prototype in Figma takes two days. A coded version of the same flow takes three weeks. Show the prototype to five users and watch where they hesitate. I've killed two product ideas at this stage for a total cost of about forty hours of my time.

Stage 5: build the thinnest working slice

One user type. One core action. No admin panel, no settings page, no dark mode. If you need to onboard users manually over a call, do it — sixteen early customers of a tool I built were onboarded by hand for the first month, and it taught me more than any analytics dashboard.

Stage 6: test, but define what "test" means

Sign-ups are vanity. Retention over two weeks is signal. Payment is proof. Choose which of those you're measuring before launch, not after, or you'll rationalize whatever number arrives.

Stage 7: iterate — or kill it

This is the stage teams skip. If your metrics hit, you iterate on the same core. If they don't, you change the assumption, not the button color. Killing an MVP after six weeks and a few thousand euros is a win, not a failure. I've done it three times and each one freed up months.

What are the 7 stages of a startup?

The MVP sits inside a longer arc. The seven stages, as most operators describe them: ideation, customer discovery, MVP, product-market fit, growth, scaling, and maturity. The MVP stage is number three, and it follows real discovery work. Teams that jump from ideation straight to building a full product skip the stage that would have saved them the most money.

• Ideation — a problem worth solving.
• Discovery — evidence the problem is real and painful.
• MVP — a working slice that tests your biggest assumption.
• Product-market fit — retention and organic pull.
• Growth, then scaling, then maturity.

You can move through the first three in weeks. The last four take years. Most of the drama lives in the middle.

How much does it cost to build an MVP?

Here's where most guides go vague. Let's put real numbers next to each path, based on what I've paid and what I've seen quoted across dozens of conversations with founders and agencies.

Approach	Typical range	Timeline	Best for
No-code / manual backend	€500 – €4,000	1–3 weeks	Service businesses, internal tools, first validation
Founder-built with a dev co-founder	€0 – €5,000 (mostly your time)	4–8 weeks	Technical founders testing a real product
Freelance developer	€6,000 – €20,000	6–12 weeks	A single well-scoped web app
Agency build	€25,000 – €60,000	3–5 months	Funded teams, B2B with compliance needs

Two rules of thumb I've learned the hard way. First, whatever a scoped estimate says, add 40% — I've never seen a build come in under. Second, the most expensive line item is almost never development. It's the features you built because a hypothetical user might want them.

Should you build it at all? A decision test

Before any budget conversation, run this check. Can you pre-sell it? If yes, sell it first — a landing page, a Stripe link, and a clear promise. If people pay and you haven't built the thing, you have a business. If they don't, you saved yourself three months.

If pre-selling isn't possible, ask whether a manual version of the service solves the problem for your first five customers. Twenty years of consulting has taught me that the manual version of almost everything is cheaper and more informative than the automated one. Build the automation only when you're drowning in manual work.

Why most MVPs fail before the code is written

The failure usually happens in discovery, not engineering. Teams get attached to a solution before they've confirmed the problem, then build an MVP designed to confirm their solution rather than test it. That's not an experiment. It's a very expensive opinion.

The fix is boring. Talk to people. Write the assumption down. Build the smallest thing that can break it. And be honest when it does — an MVP that proves you wrong in three weeks is worth more than one that proves you right in three years.

The founders I've seen get this right share one habit: they treat their MVP as disposable from day one. They expect to throw most of it away. The ones who succeed at building an MVP aren't the ones who build the best thing. They're the ones willing to build a slightly embarrassing thing, put it in front of a stranger, and hear the answer.