How to Finish a Side Project

What does "done" actually mean for a side project?

Done means a stranger can complete the one core action without you narrating over their shoulder — not feature-complete, not pretty, just usable for a single job. Before you write more code, write two lists: the one path that must work end to end, and everything you are deliberately cutting out of v1. The cut list is the more important document, because it's where scope creep gets said out loud instead of quietly committed. If your must-work path forks into more than one branch, you haven't cut enough yet.

A blunt forcing function: describe v1 in one sentence and ban the word "and." "A page where someone pastes a URL and gets back a readability score" is one project. Bolt on "and it saves their history and emails a weekly digest," and you've quietly started three projects, none of which will ever ship. When the word "and" sneaks back in, that's your scope growing in real time — send the new idea to a v2 file and keep building the one sentence.

• →One user reaches the core action in under a minute, or you drop auth entirely for v1 and add it later
• →Exactly one happy path works end to end; every edge case shows an honest error instead of crashing
• →It lives at a URL you can paste into a message, not on localhost behind three terminal commands
• →Copy is finished on the one screen that carries the product; everywhere else it's ugly-but-clear
• →Sending it to a real person makes you slightly uncomfortable — that discomfort is calibration, not a reason to keep building

How do you keep a rhythm on 5-10 hours a week?

With a full-time job, the real tax on a side project is reload cost: every time you sit down, the first stretch goes to rebuilding the mental model of where you left off. Rhythm is the fix. Two or three fixed 90-minute blocks across the week beat one heroic Saturday, because the gap between sessions stays short enough that context survives from one to the next. End every block mid-task on purpose — leave a failing test, a half-written function, or a one-line TODO naming the exact next move. Starting is the expensive part, so make the next start cheap.

Two activities masquerade as progress on a side project: researching instead of building, and polishing instead of shipping. Reading one more framework comparison feels like diligence and moves nothing. If you catch yourself with ten tabs open about state management before v1 even runs, close nine — that instinct is almost always the boring last stretch scaring you off, not a real technical decision that v1 depends on.

What systems carry a side project across the line?

Finishing depends less on staying motivated than on having a specific counter-move waiting at each place a side project predictably stalls. Name the stall, install the fix once, and stop relitigating it every session. Below are the stalls that kill side projects and the concrete rule that gets you past each.

Why do side projects die near the end — and how do you push through?

Side projects rarely die at the start; they die once the interesting problems are solved and only the unglamorous ones remain — auth, error states, empty states, deploy config, and copy that reads like a human wrote it. None of that gives you a dopamine hit or demos well, so the brain offers a flattering exit: rebuild it properly, this time with a cleaner architecture. The exit is a trap, and taking it is how a project that was almost shippable becomes a project that is unshippable again.

Push through by making the remaining work concrete and small. List what's left as verbs, not vibes — "wire up logout," "handle the empty-list state," "write the deploy config" — and do the ugliest one first each session while your attention is freshest. Refuse all visual polish until the happy path runs end to end, then ship it slightly worse than you'd like. You can improve a thing that exists at a real URL; you cannot improve a rewrite that no one has ever used.

When should you kill a side project instead of finishing it?

Not every side project deserves to be finished, and forcing a dead one across the line wastes weeks you could spend on the next. But the honest kill signals are not the same as boredom. The real ones are narrow: you've genuinely stopped believing anyone — you included — wants the outcome, or the smallest shippable version is still months out even after you've cut hard twice. Boredom near the end means push through; a real loss of belief in the outcome means stop.

If you kill it, kill it on purpose. Write one line on what you learned and what you'd do differently next time, so the project becomes a data point instead of a vague background sense of failure. A clean, deliberate kill hands back the hours and attention the next project will need — a far better result than a half-built thing quietly rotting in a repo you've started avoiding.