Build journal
The graveyard of projects
There are domain names, GitHub repositories and ideas we promised ourselves we'd finish.
Ndiaga Ndiaye4 min read
Build journalShare on LinkedIn
Build journal
There are domain names, GitHub repositories and ideas we promised ourselves we'd finish.
Somewhere in a GitHub account, there's a repository whose last commit was a long time ago.
The README is ambitious.
So is the feature list.
There may even be a beautiful logo.
And then nothing.
No announcement.
No farewell.
Just one final change, followed by a very long silence.
Welcome to the graveyard of projects.
I suspect many developers know this place.
I certainly recognise the road that leads there. 😅
You spot a problem.
Imagine a solution.
Choose a stack, create a repository and sketch a few screens.
The first hours feel amazing.
Anything is possible.
The app has no bugs because it barely has any features.
It has no unhappy customers because it has no customers.
And in your head, the finished product already works perfectly.
That may be the most dangerous moment.
Because building something can feel far more exciting than finding out whether anyone actually needs it.
First, you build.
Then you have to explain the product.
Get people to notice it.
Answer questions.
Fix unexpected behaviour.
Write documentation.
Pay for hosting.
Come back the next day.
And the day after.
And keep going even when nobody seems particularly impressed.
The work becomes less glamorous.
Fixing a form doesn't give you the same satisfaction as launching a new homepage.
Talking to a frustrated user isn't as fun as choosing an architecture.
But this is often where a prototype begins to become a real product.
It's tempting to assume abandoned projects were simply bad ideas.
Sometimes they were.
Not always.
Some become too expensive to maintain.
Some solve a problem that's too small.
Others lose their place to work, family or financial responsibilities.
And some only needed to exist for a few weeks to teach us something.
That's not always easy to admit.
Especially after telling people how exciting the idea was.
But giving up on a project isn't necessarily giving up on ambition.
Sometimes it means refusing to keep investing in a hypothesis that no longer holds.
When people aren't using a product, a developer's instinct can be predictable.
Add something.
A dashboard.
A premium plan.
A search engine.
An animation.
As though the application is one feature away from becoming essential.
I know the temptation.
I even wrote about it in One feature too many.
What we sometimes need to add isn't another line of code.
It's a conversation with someone who might genuinely use the product.
With KUMBA and KAMIT, I regularly ask myself the same question: what still deserves my time?
I could spend every evening starting something new.
Ideas aren't in short supply.
The capacity to support all of them properly is.
So I'm trying to separate three things.
What I want to create.
What I can maintain.
And what actually helps someone else.
Those three don't always line up.
An abandoned project shouldn't become a trap for its users.
If it stores data, think about how people can retrieve or delete it.
If it still claims to offer a service, don't pretend it's actively maintained.
If it uses secrets or paid resources, shut them down safely.
And if the code could help someone else, perhaps it deserves one final piece of documentation.
Even a project that ends can end responsibly.
I don't think having fifty unfinished repositories is a badge of honour.
But I don't think it's something to be ashamed of, either.
You may find a bad decision, a good intuition, a technique you learned or an idea that simply arrived at the wrong time.
None of this means you should keep the project alive forever.
It just means there may be a lesson worth keeping.
A project doesn't have to become a company to have taught you something.
We just need to stop treating every new idea like a promise we'll have to honour for the rest of our lives.
Otherwise, we're going to need a bigger graveyard. 😅
