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 skipping 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 to build. They cut 5, feeling decisive. Now with 18 features, they face 14 months of work for a two-person team. Six months in, they've half-built everything, run out of money, and shut down.
The MVP that could 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 original 23.
This is the pattern. Founders cut 22%. They needed to cut 87%. Cutting is hard because every feature feels essential when you imagine a complete product. Nobody imagines the product as a coupon for one specific test — which is what an MVP is.
Here's my process for a real MVP.
Step 1: Write down the riskiest assumption. Not the riskiest technical assumption — the riskiest business assumption. If it's false, there's no business. Examples: "small business owners will pay $50/month," "doctors will choose us over the existing tool," "this demographic will adopt a new daily habit," "unit economics work at scale-target X." There's always one. Write it as a single sentence.
Can't pick one? You don't understand your business. Talk to twenty potential customers first.
Step 2: Design the cheapest experiment to test that one assumption. Not the product. The experiment. It may not involve software. It might be a landing page, a manual workflow, a Zapier chain, a clickable Figma prototype, a $200 ad campaign with a fake checkout. The experiment's 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 — just perform the service manually for ten customers and measure the economics.
The urge will be to add things. "We need user accounts." "We need a dashboard." "We need email notifications." Each is a delay disguised as a feature. Ask: does the experiment require this to produce a verdict? If no, 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 asking customers for real cards. Vague intent ("I would buy this") isn't real evidence. A swiped card is. A signed pilot agreement is. Internal optimism isn't.
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 tackle the next-riskiest assumption or pivot/kill the business.
This loop runs maybe four to six times before you have something approximating a real product. Each loop should be cheaper than the last — meaning each "no" outcome 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:
The cost of code is going to zero, and the MVP playbook has to follow. In 2022, Bubble, Glide, Softr, Airtable, Zapier were the go-tos. In 2026, Claude Code, Cursor, Codex, and others produce a working Next.js or Django app faster than Bubble, and it's yours — a real repo to fork, scale, and extend. The no-code platform tax is gone.
Use multiple AI tools in rotation. Senior operators use Claude Code for architecture-level reasoning and refactors, plus Cursor or GitHub Copilot for in-line completions, and swap in Codex, Gemini, or Aider for specific niches. The models have different blind spots; swapping is worth it to catch mistakes.
Avoid the trap: AI coding is chemically fun in a way regular engineering isn't. The dopamine hit of watching code stream into your editor is real, and it'll eat your day producing things that don't advance the business. Stay disciplined. Ship something that runs in front of a customer. Measure its impact. Then do another loop. When code costs nothing, the constraint is what's worth writing — and founders who lose confuse output velocity with progress.
Do things that don't scale. Paul Graham's essay is still correct. Stripe was installed in person by founders. DoorDash delivered the food themselves. Airbnb shot the listing photos. During the MVP phase, test if the transaction is real by running it manually and learning 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 with hard budgets pivot at the right time. Those without sink savings into a bad idea over 18 months.
Avoid "we're building the foundation." Many founders try to build a "scalable architecture" during the MVP phase to save a rewrite later. The rewrite will happen anyway because what you build will be wrong, as the version you ship is for a different customer than the one you scoped. Stop optimizing for the rewrite. Optimize for learning.
Avoid "we're different." Every founder thinks 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 likely 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 pity you.
This is correct. The MVP should embarrass you. If not, 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.