How to Scope a Shippable V1
The fastest path from idea to something a real person can pay for.
The biggest mistake I see indie makers make isn't bad ideas — it's good ideas with bad scope. A product that tries to do too much in V1 is a product that never ships.
Here's the framework I use to cut a V1 down to something I can actually finish.
Start from the core outcome
Before listing features, write one sentence: what does this product help someone do?
Not "manage projects" — too broad. Not "send emails from a spreadsheet with one click" — that's a feature. The right level: "help a freelancer send professional invoices without touching accounting software."
Every feature you're considering either directly enables that outcome or it doesn't. Cut the ones that don't.
The must/nice/later sort
Take your feature list and sort it into three buckets:
- Must: without this, the core outcome doesn't work
- Nice: this makes the experience better but the product still works without it
- Later: genuinely useful, but not for V1
Your V1 is everything in "must" plus whatever fits in the time you've budgeted. "Nice" features are candidates if time permits. "Later" gets a note in a backlog file.
The scope creep trap
Nice-to-have features have a habit of migrating into the "must" bucket during development. When that happens, ask whether the core outcome actually requires it. Usually it doesn't.
Time-box it
Pick a ship date before you pick your features. Working backwards from a deadline forces honest scoping in a way that working forwards from an idea list never does.
Four weeks is a reasonable default for a first mini product. Two weeks if you've done this before.
The V1 question
Before you finalize scope, ask: is there a version of this product that I could build in half the time, that would still be genuinely useful to someone?
If the answer is yes, that's probably your V1.