The half-a-job problem — setting completion goals on hobby projects
AI made it easier to start hobby projects, which made the old half-finished-project problem louder rather than smaller.
I described myself recently as “the kind of person that’s half a job”. There are lots of half-finished projects around me, each one close enough to useful that I can still make a case for keeping it alive.
I had expected a month of Claude Code Pro Max x20 to help clear that pile. It did help me make things. The problem was that it made starting things much cheaper too.
During those weeks I started a gym-coach web app, an iOS companion for Health data, this blog, a type 1 coaching concept, a homelab software delivery repo and a Minecraft builder bot. That is a decent amount of work. It is also a much longer list than the one I was supposed to be reducing. The older projects did not disappear just because the new ones reached an interesting first version.
This is familiar behaviour for me. I like the point where an idea becomes real. A blank repository turns into a page I can open, a service running on the homelab or a bot responding to a command. Once that proof exists, the project immediately presents another set of possibilities. The first version starts to look temporary before I have finished it.
The tools make this easier to indulge. A change that might once have taken an evening can happen quickly enough that adding one more feature feels harmless. It rarely arrives as obvious scope creep. It arrives as a sensible improvement: a native app would make the web app more useful, a proper delivery path would make the service safer, another integration would remove a manual step. Each addition is reasonable when viewed on its own.
At work I already have ways of dealing with this. I prefer fewer, fatter tickets and end-to-end vertical slices. I want a piece of work to travel through the whole system and become usable before I split off into refinements. When costs or awkward dependencies appear, I am comfortable cutting scope. There are other people waiting for an outcome, and “done” has to mean more than an interesting branch and a convincing demo.
I have been much less strict at home. A hobby is allowed to wander. It does not need to justify itself in the same way as paid work, and I do not want every evening project to feel like another delivery plan. That freedom is part of why I do any of this.
It also gives me somewhere to hide from the boring final part. Running a project somewhere, using it regularly and keeping it alive are different from proving the central idea. They involve deployment, small bits of documentation, repairs and decisions about what I will support. Starting the next project is usually more appealing.
The definition of done I keep coming back to is deliberately ordinary. A hobby project is done when it is running somewhere, I use it at least once a week, and it does not require weekly maintenance just to remain alive.
That definition rules out some of my projects. It also stops me counting code volume or a successful first run as completion. A service that only works while I am actively tending it is still occupying the workbench.
I have three possible rules for changing this, and I do not fully trust any of them yet.
The first is to write the v1 scope on day one and ship it before allowing any v2 thinking. This is closest to the way I already work elsewhere. For the gym-coach web app, for example, that would mean deciding exactly what regular use looks like before the native companion or another data source gets a vote. The useful part of the rule is the written boundary. I cannot quietly move it later and pretend the new work was always part of v1.
The difficulty is that hobby projects teach me what they are while I build them. A boundary written too early can preserve the wrong thing. I might find that the feature I thought was central is awkward in normal use, while a small addition would make the whole project viable. I need room to learn without using learning as a permanent excuse to expand.
The second rule is harsher: no new project until two existing ones reach a defined done state. It would reduce the pile quickly if I followed it. I suspect I would instead spend time negotiating with myself about what counts as a new project. A Minecraft experiment, a small Home Assistant change and a weekend script can all be described as extensions of something that already exists if I want them badly enough.
It also risks turning leisure into queue management. I do not want to sit down with an idea I am excited about and discover that I first owe myself two releases. That sounds organised, but it may be a good way to stop enjoying the work.
The third is an abandon date. If I am not actively working on a project by the date I set, I archive it without guilt. This is the kindest rule and perhaps the most honest. Some ideas have already done their job once they have taught me something. Leaving every repository notionally active does not honour that work. It just means I keep carrying the possibility of returning to it.
Archiving still feels uncomfortable because these projects are rarely obvious failures. Most of them work a bit. They have a useful screen, a promising integration or enough structure that another evening could move them forward. The unfinished state keeps making a small claim on my attention because completion always appears close.
AI has made that distance harder to judge. It can produce a lot of visible progress quickly, especially at the start. The later questions remain mine: whether the thing deserves a place to run, whether I will use it, which rough edges matter and how much maintenance I am willing to accept. Faster implementation has not answered those questions. It has let me postpone them across more projects at once.
I am going to try the written v1 boundary and the abandon date. I am less convinced by the two-project gate, although that may be because it is the one most likely to stop me starting something tomorrow.
The current list is still longer than it was at the start of that month. Several entries run, several nearly run, and a few mainly exist as a good reason to open the editor again. I have not decided which of those I am ready to archive.