Chapter 2 of 8 · 5 checks · 2 min
Scope the first version
Ship the smallest version that solves the core problem well. Everything else waits until users ask for it.
Define the one job the first version must do wellMust
Why it matters and how to check
Write down the single task your product helps users complete. Every feature in version one must support that task. Accounts, teams, dark mode, integrations and admin dashboards can usually wait.
Check it: you can state the core job in one sentence, and every planned feature supports it.
Do
- Cut any feature that does not support the core job
Avoid
- Building settings pages before the main feature works
Do things by hand before you automate themShould
Why it matters and how to check
In "Do Things that Don't Scale", Paul Graham describes early teams doing work manually behind the scenes and delighting early users with personal attention. For an indie product, that might mean onboarding users yourself, generating a report by hand, or answering every support message personally.
Manual work teaches you what to automate and keeps you from building systems nobody needs.
Check it: you have listed which parts of the product you will handle by hand at first, and you only automate them when the manual work becomes a real bottleneck.
Do
- Onboard your first users personally
Avoid
- Building automation for a process you have run zero times
Set a launch date and protect itMust
Why it matters and how to check
Side projects drift without a deadline. Pick a launch date a few weeks out, list what must be done by then, and move anything else to after launch.
A launch is not a single event; you can launch again later with improvements. Shipping early gets you real feedback.
Check it: you have a written launch date and a short must-have list, and anything else is on a later list.
Do
- Keep a separate "after launch" list for new ideas
Avoid
- Moving the date every time you think of a feature
Use a stack you already know and keep running costs lowShould
Why it matters and how to check
Launch is not the time to learn a new framework. Use tools you are productive with, managed services where they save time, and hosting tiers that fit your expected usage.
Set billing alerts on every cloud account so a bug or a spike does not produce a surprise bill.
Check it: the product uses tools you know well, and every paid service has a billing alert.
Do
- Set spending limits or alerts on cloud accounts
Avoid
- Rewriting the backend in a new language before launch
Make the core flow reliable, secure and backed upMust
Why it matters and how to check
Early users forgive missing features but not lost data or broken sign-ups. Test the main flow end to end, handle errors with clear messages, use HTTPS, store secrets outside the code, and set up automatic database backups that you have tested restoring.
Check it: you have run the core flow from sign-up to result on a clean account, and you have restored a backup at least once.
Do
- Test a backup restore before launch
Avoid
- Committing API keys to the repository