How to Build a Minimum Viable Product

What an MVP is (and isn't)

An MVP is not a bad version of your final product. It's the smallest test that gives you a definitive answer to one question: will someone give me their time, money, or attention for this? Anything beyond that is scope creep.

If you're not embarrassed by the first version of your product, you've launched too late. — Reid Hoffman

A 4-week MVP timeline

Week 1 — decide what to prove

• Write the one hypothesis you're testing in a single sentence.

• Define the metric that proves or disproves it.

• Talk to 10 people in your target ICP. Ask, don't pitch.

Week 2 — design the smallest possible test

• A landing page counts.

• A Notion doc counts.

• A Loom + Calendly booking counts.

• Working software rarely counts at this stage.

Week 3 — ship it

Send it to your ten people first. Fix the obvious. Then post it publicly.

Week 4 — read the signal

Signals to trust: money in the bank, time on a call, unprompted referrals. Signals to ignore: page views, likes, this is cool.

The code trap

The most expensive MVPs are the ones with the most code. If you're a technical founder, this is your default failure mode. Watch for it.

// Before building this feature, ask:
//   1. Would a Google Form work instead?
//   2. Would a manual back-office work instead?
//   3. Would a Loom work instead?
// If any answer is "yes" — do that first.

When to stop iterating on the MVP

You stop when the same customer keeps coming back without prompting. Retention is the first honest signal that you've built something worth scaling.