Every developer owns a private graveyard: the folder of projects that were exciting for three weekends and untouched since. The pattern is so universal it deserves study rather than shame — because the forces that kill side projects are structural, and structure is something developers know how to refactor.
The classic death is not the beginning, which is euphoric, and not the middle, which is honest work. It is the last twenty percent — auth, error states, deployment, the settings page — where novelty has worn off and only discipline remains. Understanding that the wall is scheduled is the first step to building for it.
Scope is the project
The single strongest predictor of finishing is the size of version one. Not the idea's size — the version's. 'A recipe app' is unfinishable; 'a page where I paste a URL and get the ingredient list, deployed, usable by me' is a fortnight. The discipline is defining done before writing code: one sentence, one user (you), one core loop, written where you will see it. Everything else — accounts, sharing, dark mode, the mobile app — goes in a file named LATER, which is where enthusiasm can be safely parked without being argued with.
The professional instincts that serve you at work actively sabotage you here. Production-grade architecture, test coverage, scalable infrastructure — for a tool with one user, those are procrastination wearing a hard hat. A side project earns engineering rigour by surviving long enough to need it. Version one's stack should be the most boring thing you already know, deployed the laziest way that works.
Momentum mechanics
Side projects run on a different fuel than jobs: there is no external deadline, so the system must generate its own pull. Small sessions beat heroic weekends — forty-five minutes that end with one visible change keep the loop warm, while the every-few-weeks marathon spends its first hour just remembering the code. End every session by writing the next session's first task in one line; future-you starts moving instead of deciding, and starting is the whole battle.
Ship embarrassingly early to an audience of one: yourself, using the thing for real. Real use is the only feedback that reliably re-ignites motivation — the missing feature you personally crave beats any roadmap, and the first time the tool actually saves you a minute is the moment the project stops being homework. If it is meant for others, show it while it is still slightly shameful; one stranger's 'oh, I'd use that' funds a month of evenings.
Finished is a decision
Here is the reframe that empties graveyards: finished does not mean feature-complete — it means version one does its one job and you declared it so. Cut until the core loop is reachable, ship it, tag it, tell someone. Whatever happens next — growth, abandonment, a rewrite — it happens to a finished thing, and you become a person who finishes, which compounds across every project after.
And grant yourself the honest exit: some projects are done teaching you what they had to teach by week three, and archiving them deliberately is not failure, it is portfolio management. The graveyard's real cost was never the dead code — it is the quiet belief that starting is all you know how to do. Break that once, at any scale, and side projects turn back into what they were supposed to be: the most fun a developer has all week.