There's a graveyard on most people's hard drives, and everything in it is nearly finished.
The app that works but has no error handling. The site that needs one more pass on the copy. The tool that does the thing it was built to do, sitting on a laptop, never shown to anyone. All of them stopped at around 80%, and none of them stopped because the person got bored.
They stopped because the last 20% is a different kind of work, and nobody plans for that.
What's actually left at 80%
Not a fifth of what you've done. A collection of the specific things you've been deferring, which is a very different list.
The first 80% is the part you wanted to build. It's the interesting problem, the bit with novelty in it, the reason you started. Every satisfying decision lives there, and progress is fast because the work is enjoyable and the failures are private.
The last 20% is the residue. Error handling. Edge cases. Copy that has to be written rather than sketched. Settings. The thing you'd need to do to let someone else use it. It's dull, it's fiddly, and — most importantly — much of it exists only because other people will see the thing.
So the ratio is honest about volume and wildly wrong about difficulty. The remaining fifth routinely takes as long as the first four, and it feels worse throughout.
The one task that stops everything
Look closely at a stalled side project and there's usually a single item doing the blocking.
Not a hard technical problem. Something like: show it to somebody. Put it online. Send it to the person it was built for. Ask a friend to try it.
That task is small, takes fifteen minutes, and is the only one on the list that carries a verdict. Everything else can be done privately with no risk attached. This one converts a private thing into a judged thing, and until it happens the project remains in the comfortable state of not yet being any good rather than definitively being mediocre.
The tell is that work continues while that task doesn't. New features get added. The database layer gets refactored. Requirements get invented — it should probably handle recurring appointments before anyone sees it — each of which pushes the fifteen-minute task further away while looking like diligence.
Three reasons this happens more here than at work.
Nobody is expecting it. There's no client, no deadline, no colleague waiting, so the only thing pushing the exposed task forward is your own willingness to do an unpleasant thing for no external reason.
The identity stakes are higher, not lower. A side project is chosen, so it says something about you in a way that assigned work doesn't. If the thing you built in your own time, for your own reasons, turns out to be unimpressive, that's a more personal result than a mediocre report.
And there's always more building available. Software in particular can absorb infinite work, and every hour spent adding something is an hour spent not shipping, while producing all the sensations of progress.
What actually gets it out
Three moves, in order of usefulness.
Name the blocking task explicitly, on the goal, in the words that make it uncomfortable. Not finish the beta but give it to the receptionist and watch her use it. Written down like that, it becomes obvious that everything else you've been doing was adjacent to it.
Then shrink it until the exposure is survivable. One person, not ten. A friend rather than a stranger. Show it in person rather than sending a link, so you can see the reaction and answer questions, which is far less exposing than silence. The goal is to make the first judgement small enough to accept, because after the first one the task stops being frightening.
Then freeze the scope, in writing. A list of what's in, dated, with everything else explicitly out until after the first person has used it. This is the only defence against invented requirements, and it works because you can see, later, that recurring appointments were not on the list you wrote in September.
The case for leaving them unfinished
Worth saying, because the assumption that every project should ship is doing damage too.
Plenty of side projects have already delivered their value. You built it to learn the framework, and you learned the framework. The finishing work would teach you nothing and take three weekends. Abandoning that is not a failure of will, it's a correct assessment, and the guilt attached to it is unearned.
Some are also better abandoned than shipped. A tool that solves your problem and nobody else's doesn't need packaging, documentation and support — it needs you to keep using it privately, which is what it's for.
The distinction is what you feel about the blocking task. If the thought of showing it to someone produces a flinch, that's fear and the project is stalled. If it produces indifference — you can imagine showing it and simply don't care what they'd say — the project is finished and you can stop. Those are genuinely different states and only one of them needs fixing.
The clinic scheduler
He builds a scheduling tool for his partner's clinic over about six months of evenings. By August it works.
September has four sessions in it. Two on refactoring the database layer, one redesigning the settings page, one writing a list of what's left. All real work. None of it touches the next actual step, which has been the same since mid-August: give it to the receptionist and watch her use it.
In the second week he decides it should handle recurring appointments before anyone sees it. That's a new requirement, invented that evening, and it adds a month.
By October he's saying it's nearly there, just tidying a few things, and the sessions have stopped. 41 days quiet by the end of the month.
What breaks it is a conversation where he's asked what the next step is, and hears himself answer honestly. The move that follows is deliberately small: no recurring appointments, no settings redesign, just sitting with the receptionist for twenty minutes on a Thursday while she books three appointments.
She finds two things wrong in the first five minutes, both trivial, neither of which he'd have predicted. That's the entire value of the last 20%, and it was available at any point since August.
What the counter would have shown
Not that the project was going badly — the September sessions all cleared the gap, because work was genuinely happening.
What it would have shown is October: 12 days, then 26, then 41, sitting at the top of the list. And the notes underneath, read together, showing four sessions of building and none of showing.
That's the pattern the number surfaces and the log explains. A project that goes quiet at 80% has almost always been avoiding one specific fifteen-minute task, and it's usually visible in the record long before it's visible to the person keeping it.
Related: Why the goals you care about most go quiet first · What a goal looks like the week before you lose it · The thirty-minute unstick
Share: