The first ten minutes are the loudest
A short note on building things small enough to ship before you stop believing in them.
Why most side projects die
Most projects don't fail because they're bad ideas. They fail because the gap between starting and shipping is too long. By the time you're four weekends in, the spark is gone, the next shiny thing has appeared, and the codebase is a graveyard of half-finished features.
The trick is to make the first usable version small enough that you can build it before the spark dies. For most people, that's about a week of focused effort.
A working definition
A v0 is the smallest thing you can put in front of a stranger and learn whether they care. It is not the smallest thing you are proud of.
Those are very different bars, and conflating them kills more side projects than anything else.
What you actually need
- One core action that works end-to-end
- One way to see the result
- Some way to capture interest from people who showed up
That's it. Everything else — accounts, themes, integrations, dark mode — comes after you have evidence anyone wants the thing.
Anti-patterns to avoid
| Pattern | Why it kills you |
|---|---|
| Account system before launch | A week of work, zero validation value |
| Multiple themes on day one | Splits attention from making one perfect |
| Comparison page with rivals | You don't have users yet — write later |
| Pricing page before traffic | Premature optimization of the wrong thing |
A useful question to ask yourself
Before you add a feature to your v0 backlog, ask:
Will the absence of this feature
prevent a stranger from understanding
what this product does?
If the answer is no, it's a v1 problem. Maybe a v2 problem.
In summary
Ship in a week. Watch what happens. Decide what to build next based on what real people do, not what you imagined they'd do at the planning stage.