Scoping the MVP

"Build an MVP" is the most repeated and most misapplied advice in startups. The right question is not "what's the smallest thing I can build?" It's "what's the smallest thing that tests the specific risk I actually have?" Those give different answers, and picking the wrong one wastes months.

The concept

MVP means minimum viable product, the smallest build that produces validated learning. The word doing the work is viable, and it's the one everyone drops.

Two failure modes bracket this stage, and most projects hit one:

Death by breadth. You build for "people who want to be productive," so every feature is arguably in scope. Four months later you ship nothing.

Death by minimum. You take "minimum" literally, ship something genuinely thin, nobody cares, and you conclude the idea was wrong when actually the product was too shallow to test anything.

The escape from both is the same: diagnose your risk first.

Diagnose the risk, then choose the MVP

Your MVP shape depends entirely on which question you don't know the answer to:

The last row is the one nobody warns you about. If your differentiation is depth, a course, a data set, a library, a curated collection, then a thin version doesn't test your hypothesis. It tests a different, worse product that already exists.

Example: if the market already proves people will read short daily content (it does), and your bet is "a structured, sequenced course retains better than a feed," then ten pieces of content tests nothing. You've built a feed. The structure is the hypothesis.

Diagnose honestly. Most products have demand risk, and for those the mantra works perfectly. A minority have depth risk, and for those the mantra is actively harmful.

Vertical slice, not horizontal layer

When you do build, build one complete flow end to end rather than every screen at 40%.

 ❌ HORIZONTAL — everything half-built, nothing usable
    ┌──────────────────────────────────────────┐
    │ signup │ browse │ create │ share │ pay    │   all 40% done
    └──────────────────────────────────────────┘
                 nothing works end-to-end

 ✅ VERTICAL — one complete path, fully working
    ┌────────┐
    │ signup │ ██ 100%
    │ create │ ██ 100%   ← one user can do one real thing,
    │  save  │ ██ 100%     completely, and you can learn from it
    └────────┘
      browse / share / pay  → not yet

A vertical slice can be given to a real person. A horizontal one can't be given to anyone.

The kill list is the product decision

For every feature you're not building, write it down with a reason and a version number.

"Later" is an open loop that costs you attention every time you think about it. "v1.1, because it depends on data we won't have until we have users" is a settled decision. The list is what makes scope hold.

Scope expands silently through compliance

The trap nobody plans for: adding a capability drags requirements behind it.

• Add accounts → you now need account deletion (app store requirement), password reset, GDPR data export
• Add payments → you need refunds, receipts, tax handling, restore-purchases, subscription disclosure
• Add user content → you need moderation, reporting, blocking
• Add anything for children → COPPA, parental consent
• Add health data → HIPAA-adjacent obligations, stricter store review

Check the store guidelines and legal requirements for each capability before you commit to it, not after (Chapters 36, 40).

📐 Best practice

Write the churn hypothesis before the feature list. One sentence: "Users will stop using this on day ___ because ___." Most products have one dominant failure mode and it's usually knowable in advance. Architect against that sentence before anything else, it's the highest-leverage sentence you will write.

Define your riskiest assumption, then design the cheapest test. That's the whole method.

Timebox, then negotiate scope, never the date. A fixed date with negotiable scope ships. Fixed scope with a negotiable date ships eventually, which for a solo founder often means never, because scope always finds new things to want.

Build one vertical slice first. One user, one complete job.

Decide free vs paid during scoping, not after. It determines what must be built to a shippable standard, and it shapes the product. Gate depth, never core function or safety.

Cut features, not quality. Ten features at 60% feels broken. Three at 100% feels like a product. Users forgive missing; they don't forgive broken.

Keep a written "not now" list with version numbers.

💀 Common mistakes

Applying "minimum" to a depth-risk product. Diagnose first.

Scope creep by enthusiasm. Every week a new essential feature. The kill list is the cure: new idea → write it in v1.1 → move on.

Building horizontally. Nothing works end to end, so nothing can be tested.

Perfecting the wrong thing. Founders polish what they enjoy (usually the UI, or the architecture) rather than what carries the risk.

Forgetting the unglamorous 30%. Settings, empty states, error handling, password reset, offline behaviour, loading states. It's always more than you think.

Ignoring compliance scope. Accounts and payments each drag a tail of mandatory work.

Confusing MVP with prototype. A prototype demonstrates; an MVP is used by real people and must not lose their data.

Moving the date instead of the scope. The most common and most damaging.

Building for the user you wish you had. Scope for the persona (Chapter 06), not for a power user who doesn't exist yet.

The professional workflow

 1. NAME YOUR RISKIEST ASSUMPTION
    "This fails if [X] turns out to be false."

 2. DIAGNOSE THE RISK TYPE
    demand · willingness to pay · feasibility · workflow fit ·
    a specific mechanic · depth
    → this chooses your MVP shape (see table)

 3. WRITE THE CHURN HYPOTHESIS
    "Users stop on day ___ because ___."
    → architect against this FIRST

 4. DEFINE THE CORE LOOP (Chapter 09)
    The one cycle a user repeats. That's the vertical slice.

 5. LIST EVERYTHING. Then split:
      IN v1  — required for the loop to work at all
      v1.1   — obvious next, not required to learn
      v2     — needs scale/data/users you don't have
      NEVER  — off-strategy

 6. CHECK COMPLIANCE TAIL for every v1 capability
    accounts? payments? user content? health? children?

 7. FIX THE DATE. Negotiate scope against it.

 8. BUILD THE VERTICAL SLICE. One user, one complete job.

 9. SHIP TO ~10 REAL PEOPLE before building anything else.

Tools, websites & costs

Don't buy project management software for a solo project. A markdown file with - [ ] checkboxes, committed next to the code, is better: versioned, diffable, travels with the project, readable by any tool.

Alternatives & trade-offs

No-code MVP, fastest path to a working product for CRUD-shaped ideas and marketplaces. Trade-off: ceilings on performance, cost, and customisation; migration later is a real project. Excellent for testing demand; poor for testing a novel mechanic.

Concierge MVP, you deliver the outcome manually. Highest-signal validation available (people pay for the outcome, not the software), and it teaches you the workflow you're about to automate. Unscalable by design; that's the point.

Wizard of Oz, the interface looks automated, humans do the work behind it. Perfect for testing whether people want the experience before you build the hard part. Common for AI products: run the model manually before building the pipeline.

Landing page + waitlist, cheapest, weakest. Tests the headline, not the product. Add a paid pre-order to make it meaningful (Chapter 05).

Fully-built v1, correct when you have depth risk, a genuinely proven category, or a build measured in weeks. Expensive when the demand question is still open.

Trade-off summary: the cheaper the test, the weaker the signal. Match the rigour to the size of the bet, and be honest about which risk you're actually carrying.

Checklist

• I have named my riskiest assumption
• I have diagnosed the risk type and chosen the matching MVP shape
• I have written the churn hypothesis in one sentence
• I have defined the core loop, the cycle users repeat
• My v1 is a vertical slice: one complete job, fully working
• I have a written kill list with reasons and version numbers
• I have checked the compliance tail for every v1 capability
• I know what's free vs paid, and free is genuinely useful
• Nothing safety-critical sits behind the paywall
• I have a fixed date and negotiate scope against it
• I have budgeted for the unglamorous 30%
• I know the 10 real people who get it first

📓 Case Study: when "minimum" is the wrong instinct

Project: SOLIS.

The scoping paragraph, written on day 2, is worth reading because it's messy and it contains an entire product spec:

our target audience : weak men who want to grow… all the lessons cant be just random quotes… it should be a proper aligned and well designed course… it should be little gamified so the user is hooked… im thinking if we make it 5 lessons each day then the user is bound to miss few and then user might lose interst in the app, what if we let them continue from where they left… but put a cap of 5 lessons at max per day…

Buried in there is the churn hypothesis, arrived at before any code:

people miss days → they feel behind → they quit

That one sentence generated the entire architecture of the product: a queue instead of a calendar, a forgiving streak, a daily cap, and a hard rule that the app never tells a user they're behind (Chapter 09). Writing down how you expect to fail, before you build, is the highest-leverage move in this chapter.

The depth-risk diagnosis. Standard MVP advice would say: ship 10 lessons and a paywall. That would have been a serious misread, and the reasoning is the transferable part.

The hypothesis was not "will people read short Stoic content?", a competitor with 4M+ users already proved that. The hypothesis was "will people pay for a structured 90-day course rather than a journal?" You cannot test that with 10 lessons, because the structure is the thing being tested. Ten lessons is a quote app, the exact product SOLIS was differentiating against.

So v1 was genuinely large: 450 authored lessons across 6 phases, 900 scenario questions, a rank system, a progress dashboard, a 19-question onboarding funnel, subscriptions, sync, sign-in, and account deletion. Not minimal, but it was the minimum that tested that hypothesis.

The kill list did the work. Ten features were written down as deferred, each with a reason and a version:

Any three of those would have added a week. Writing "no, and here's why" converts a recurring temptation into a settled fact.

The compliance tail arrived exactly as this chapter warns. Adding accounts made in-app account deletion mandatory under Apple's Guideline 5.1.1(v), an edge function plus a UI flow that appeared in no plan. Adding subscriptions dragged in Restore Purchases and a full disclosure block. Neither was scoped; both were discovered late.

⚠️ Deviation: the date moved instead of the scope.

On day 20, with a launch target of ~August 10 and a launch-readiness checklist in progress, the direction changed:

"dont worry about the release date, that is not a hard boundation, we can extend if needed, but the mvp should be ready with the features i mentioned"

The feature in question, 900 applied scenario questions, was genuinely valuable and became the product's second-strongest mechanic. The decision is defensible.

The framing was not. The status file recorded the outcome as "no fixed new date." Four days later the project still had no date, and as of the last entry it remains unlaunched with zero users.

The correct version of the same decision: ship v1 on August 10 without scenario questions; ship them as v1.1 three weeks later. Identical eventual product, real user data three weeks earlier.

Deferring a feature is a scope decision. Deferring the date with nothing to replace it is deferring learning, and learning is the thing an MVP exists to produce.

Lessons

1. Diagnose your risk before applying MVP advice. "Minimum" is right for demand risk and harmful for depth risk.
2. Write the churn hypothesis before the feature list. One sentence, architected against, beats a roadmap.
3. Build vertical, not horizontal. One complete job beats every screen half-done.
4. The kill list is the product decision. Reasons and version numbers turn temptations into settled facts.
5. Capabilities drag compliance behind them. Accounts, payments, user content, health, children, check before committing.
6. Protect the date, negotiate the scope. Moving the date without setting a new one is how projects quietly stop.
7. Cut features, not quality. Three things at 100% beats ten at 60%.
8. Budget for the unglamorous 30%, settings, empty states, errors, offline.
9. An MVP exists to produce learning. If a decision delays learning, it's not a scope decision, it's a delay.

Next: Chapter 08: Requirements and Roadmapping →