If you looked at my “projects”, you’d probably find a mix of:
- things that are working and actively used
- things that reached a solid, usable state
- and a pile of half-built, half-tested, “I’ll come back to that” ideas
And that last category? There are a lot of them.
Not because they failed.
Not because they were bad ideas.
But because they’d already done their job.
Not everything is meant to be finished
There’s a certain type of project that starts the same way every time:
- you get an idea
- you go all-in for a few hours (or days)
- you learn something new
- you prove a concept works
And then…
You stop.
Not out of laziness — but because the interesting part is over.
The question has been answered.
The difference between “useful” and “curiosity-driven”
Over time, I’ve realised there are two very different types of projects:
1. Utility projects
These are the ones that:
- solve a real problem
- get integrated into daily use
- get maintained, refined, improved
They need to be finished (or at least stable), because they’re relied on.
2. Curiosity projects
These exist to answer questions like:
- “Can I read this signal?”
- “What’s actually inside this data?”
- “Will this approach even work?”
Once you’ve got the answer… the value drops off quickly.
Finishing them beyond that point often adds very little.
The dopamine trap (and why it’s not all bad)
There’s definitely a dopamine hit in starting something new:
- new idea
- new direction
- new problem to solve
That early phase is fast, engaging, and rewarding.
The later phase?
- polishing
- documenting
- edge cases
- making it “production ready”
That’s slower, and honestly… less interesting.
But here’s the important bit:
Not every project needs that second phase.
What actually does get finished
The projects that matter — the ones that stick — are different.
They usually have at least one of these:
- a real-world use case
- repeated use over time
- integration into something bigger
- or someone else depending on them
Those do get finished.
Not because of discipline alone, but because they naturally justify the effort.
The hidden benefit of “unfinished” projects
Those half-finished ideas aren’t wasted.
They leave behind:
- knowledge
- reusable code
- understanding of what doesn’t work
- shortcuts for future builds
You might abandon a project, but you don’t lose what you learned building it.
And that compounds over time.
Why forcing everything to completion doesn’t work
There’s a common idea that:
“You should finish what you start”
That sounds good on paper.
In reality, it often leads to:
- dragging out projects long past their useful life
- losing interest entirely
- avoiding new ideas because of “unfinished guilt”
Sometimes the right move is to stop.
A better way to think about it
Instead of asking:
“Did I finish this?”
A better question is:
“Did I get what I needed from this?”
If the answer is yes:
- you learned something
- proved something
- built something reusable
Then the project did its job.
The important distinction
Not finishing everything isn’t the same as not finishing anything.
There’s a clear difference between:
- abandoning useful, important work
- and moving on from exploratory ideas that have already delivered value
Knowing which is which is the key.
The takeaway
Some projects are meant to become tools.
Some are meant to become knowledge.
Both are valid outcomes.
And sometimes, stopping at the right moment isn’t failure —
it’s just recognising that the goal has already been achieved.
No responses yet