Google "how to build an MVP," and you'll find a thousand articles: identify the problem, define the audience, list features, build the minimum set, launch, iterate. This advice is as useful as "to make a cake, combine ingredients and bake." Nobody fails at MVPs for not following the checklist. They fail because they can't cut the scope enough to ship.
The hard part of an MVP isn't building. It's killing.
Here's what actually happens. A founder lists 23 features they want. Realizing it's too much, they cut 5. Feeling decisive, they now have 18 features — 14 months of work for a two-person team. Six months later, they run out of money and shut down.
The MVP that would have worked had three features. Two were on the original list. One emerged after talking to real customers, who didn't want any of the 23 features.
This is the pattern. Founders cut 22%. They needed to cut 87%. Cutting is hard because every feature feels essential when imagining the product as a whole. Nobody imagines the product as a coupon for one specific test, which is what an MVP is.
Here's the process I use to get to a real MVP.
Step 1: Write down the riskiest assumption. Not the riskiest technical assumption — the riskiest business assumption. The thing that, if false, means no business. Examples: "small business owners will pay $50/month," "doctors will choose us over the existing tool," "this demographic will adopt a new habit," "the unit economics work at scale-target X." There's always one. Write it as a single sentence.
If you can't pick one, you don't understand your business yet. Talk to twenty potential customers first.
Step 2: Design the cheapest experiment to test that assumption. Not the product. The experiment. It may not involve software. Often, it's a landing page, a manual workflow, a Zapier chain, a clickable Figma prototype, a $200 ad campaign with a fake checkout. The output is evidence, not a product.
If you're writing a 20-page spec, you've stopped designing an experiment and started designing the product. Stop. Re-scope.
Step 3: Build only what the experiment requires. Discipline matters here. If the experiment is "will doctors choose us side-by-side," you don't need a working clinical product — just a high-fidelity demo. If it's "will small businesses pay $50/month," you don't need a billing engine — just a landing page with a Stripe checkout. If it's "can we deliver this service profitably," you don't need software — perform the service manually for ten customers and measure the unit economics.
The pull will be to add things. "We also need user accounts." "We also need a dashboard." "We also need email notifications." Each is a delay disguised as a feature. Ask: does the experiment require this for a verdict? If not, don't build it. Build it later if validated. Don't build it if invalidated.
Step 4: Run the experiment in public. Put real money on the line — your own for ads, or ask customers for real cards. Vague intent ("I would buy this") isn't real evidence. A swiped card or signed pilot agreement is.
Step 5: Write down what you learned in one sentence. If you can't, you ran a bad experiment. If you can, you know what to do next — either the next-riskiest assumption (continue), or that this business doesn't work (pivot or kill).
This loop runs four to six times before you have something approximating a real product. Each loop should be cheaper than the last in the wrong direction — meaning each "no" should be discovered with less capital. The total cost of finding out if your business works should be a fraction of building the full thing.
A few tactical tips:
Use the no-code stack. Bubble, Glide, Softr, Make, Zapier, Airtable, Notion-as-database. The 2026 no-code ecosystem can build 80% of what your MVP needs quickly. The downside is you can't scale past a few hundred customers. That's fine. Rebuild once you have evidence. Spending engineering time on a production-quality version before evidence is the most expensive mistake.
Do things that don't scale. Paul Graham's essay is still correct. Stripe was installed in person by the founders. DoorDash drove the food themselves. Airbnb shot the listing photos. During the MVP phase, you're testing if the transaction is real. Run it manually and learn what's hard before automating.
Set a hard budget. Decide on day one how much money and time you're willing to spend before re-evaluating. If the budget runs out without validation, stop and reassess — don't keep going on momentum. Founders who set and stick to a hard budget pivot at the right time. Those who don't sink their savings into a bad idea over 18 months.
Avoid the trap of "we're building the foundation." Many founders try to build a "scalable architecture" during the MVP phase, thinking they'll save a rewrite later. The rewrite will happen anyway because what you build will be wrong. The version you ship is for a different customer than you scoped. Stop optimizing for the rewrite. Optimize for learning.
Avoid the trap of "we're different." Every founder believes their case is special enough that normal rules don't apply. Almost none are. If you argue your industry, customer, or product is unique enough to need the full version before testing — pause. You're almost certainly wrong. MVP rules apply to telehealth, fintech, defense tech, biotech, deep tech, and consumer apps. The substrates differ. The discipline doesn't.
The hardest thing about MVPs. You'll feel embarrassed by what you ship. It won't feel like a real product. The UI will look bad. The marketing will feel weak. Your engineer friends will feel sorry for you.
This is correct. The MVP is supposed to embarrass you. If it doesn't, you over-built. Reid Hoffman said: "If you're not embarrassed by the first version of your product, you've launched too late." It's a quote, not a substitute for reality, but it points to something real. The cost of polish is time. Time is the resource you don't have.
Ship the embarrassing thing. Measure what happened. Decide what to build next. That's the entire game.