Ask somebody what their app does and you'll often get a list. It tracks your workouts, and there's a social feed, and meal plans, and a chat, and eventually AI coaching.
That app will never ship. Not because the person can't build it, but because the list has no natural end. Every feature suggests two more, and "almost done" stretches out in front of you forever.
The useful skill here is subtraction, and it's genuinely uncomfortable, because every cut feels like you're making the thing worse.
Your first version should be a bit embarrassing
There's a well-worn line in software: if you're not slightly embarrassed by your first release, you left it too late.
That sounds like permission to ship rubbish. What it actually means is that you can't learn anything from an app nobody has used. Every feature you add before launch is a guess, and guesses stack on top of each other. Ship the small thing, watch what really happens, then build the next part from evidence instead of imagination.
Think of version one as the fastest way to find out whether you're right, rather than as the product.
The question that does the cutting
Instead of "what should this do," a sharper question is: what am I least sure about, and what's the smallest thing that would tell me if I'm wrong?
Every idea has one assumption holding the rest of it up. Find that, build only enough to test it, leave the rest for later.
Say your idea helps freelancers chase unpaid invoices.
If what you're unsure about is whether people would let an app email their clients, then version one is essentially a button that sends one reminder. No dashboard, no analytics, no multi-currency.
If instead you're unsure whether people can be bothered to enter their invoices at all, version one is just the entry part, and you do the chasing manually behind the scenes while nobody's looking.
Same idea, two completely different first versions, because the risky bit sits in a different place. Most people build all of it and end up learning neither thing.
Writing down what you're not building
This is the step people skip, and it's the one that actually protects you.
Write down, explicitly, what version one leaves out. Not vaguely in your head. Written down where you can look at it.
Something like: version one does one thing, for one type of person, by the shortest possible path. It doesn't have accounts if it can avoid them, or settings, or a web version and a phone version, or team support, or a dashboard, or dark mode, and it doesn't handle every edge case.
Something quietly useful happens when you write that second list. Those items stop being things you feel guilty about and become decisions you made deliberately. At week three, deep in it, when you think "I should probably add notifications," you look at the list, see notifications sitting there where you put them, and carry on.
Without the list, every passing thought feels like a requirement.
The things that genuinely aren't optional
A few things are worth the pain, and it's useful to know which.
The one thing your app is actually for, obviously. Do that properly rather than five things adequately.
Whatever stops it looking broken. If it seems half-finished, people won't trust it with anything real, and you'll learn nothing about your actual idea because they'll have left before they got there.
Anything that would be genuinely painful to add later. Most features are cheap to bolt on afterwards. A few aren't, and they're mostly about how your data is organised, which we'll get to in Chapter 2. That one's worth thinking about early.
Everything else can wait, and waiting is usually the right call.
"But what if people ask for more?"
They will, and that's the good outcome.
If somebody uses your small app and says "I wish it also did X," that's far more valuable than you guessing X in advance, because now a real person has told you. An app that does one thing well with people asking for more is in a much better position than one doing eight things nobody requested.
A quick story. My own app is the cautionary version of this. I kept building. More content, more polish, more screens, all of it decent work, none of it in front of a single user.
The trap was that building felt like progress. It's visible, it's satisfying, you can see the thing improve every day. Shipping felt exposing, so it quietly slid to next week, and then the week after that.
Months later I had something good and no idea whether anybody wanted it. Had I shipped the small version early I'd have had the same information far sooner, and probably a better app at the end of it, because real people would have shaped it instead of my assumptions.
A rough size check
Not a rule, just a gut check. If you can't describe your first version in one sentence without using "and" more than twice, it's probably still too big.
"It lets freelancers send an automatic reminder for an unpaid invoice" is shippable.
"It lets freelancers track invoices and send reminders and see analytics and manage clients and export to accounting software" is a year of your life.
If you want help cutting
Point four is the one worth keeping. Most things are fine to defer, a few really aren't, and knowing the difference before you start saves a rewrite.
Next: Getting set up with Claude →
Go deeper: Chapter 7, Scoping the MVP and Chapter 8, Requirements and Roadmapping