Shipping side projects before they get boring

Every side project I abandoned had the same shape. Week one is architecture. Week two is a component library nobody asked for. Week three is the realisation that the actual feature — the reason the project existed — has not been written yet, and by then the excitement has moved on to something else.

The fix was not discipline. It was scope. Before writing any code I now decide what the smallest publishable version looks like, and I write that sentence down. Not a roadmap, one sentence. If it takes more than a weekend to describe, it is still too big.

The second rule is that the first version ships without settings. No configuration, no theming, no accounts unless the product literally cannot work without them. Every option is a decision deferred, and deferred decisions are what stall projects.

This is less satisfying than it sounds. The things I ship this way look unfinished, and they are. But an unfinished thing that exists gets feedback, and feedback is the only reliable signal about what to build next. A polished thing that never ships teaches you nothing.