What I Learned from Shipping a Side Project

Six months ago I started a side project. Three months ago I thought I was a week away from launching. Two months ago I launched.

The timeline is familiar. The lessons from it are worth writing down.

The Estimate Problem

The first thing that slipped was time. Not dramatically — I wasn't off by a factor of ten — but the consistent optimism of early estimates accumulated into a real delay.

The pattern: I estimated time for the thing I understood, and forgot to account for the things I'd discover along the way. The integration with the third-party API would surface edge cases. The design that looked fine in isolation would need adjustment in context. The feature I thought was complete would reveal a flaw once real content ran through it.

None of this is surprising in retrospect. But it needs to be built into estimates from the start: add time for the unknown, because the unknown is reliable.

Constraints Helped More Than They Hindered

The project had a strict scope constraint: it had to be useful to me personally, and I had to be willing to use it daily. This meant features that sounded interesting but didn't serve that goal were cut quickly.

This constraint — embarrassingly simple — saved weeks. Every time I was tempted to add something speculative, I had a concrete test: would I use this? If not, not now.

The resulting product is smaller than my initial vision. It is also significantly more coherent, because every decision had to clear the same bar.

Shipping Cures Perfectionism

The version I released was not the version I imagined. The version I imagined would have taken another three months and probably still not have been finished.

Shipping changed my relationship to the project entirely. Suddenly I had real feedback — not the imagined feedback of designing in a vacuum, but actual signals from people using the thing. Problems I had spent time worrying about turned out not to matter. Problems I hadn't anticipated appeared immediately.

The first week after launch was more instructive than the preceding months of building.

What Sustainable Actually Means

For a side project, sustainable means one thing: you remain interested. The economics are usually secondary.

Interest is a function of progress. Progress requires shipping, getting feedback, and improving. The loop has to turn.

My mistake, repeated in project after project, is treating completion as a gate before the loop can start. But completion is a fiction for anything that interacts with the world — there's always more to do. The loop has to start earlier.

The next project will have a release date from day one. Not a target — a commitment, to myself, that something will ship by that date. What ships might be smaller than planned. But it will ship.