Last year, during an insomnia-fueled 3 AM session, I opened my GitHub and started doing something no developer should ever do at that hour: browsing abandoned repositories.
Twenty-three. All private. All mine.
The oldest was from 2021: a machine learning trading bot that was going to "change my financial situation." It lasted 4 commits and a requirements.txt pinned to a TensorFlow version that no longer exists.
The most recent — just three months old — was a course platform for Latin American developers. That one had momentum: 87 commits, full Figma designs, a registered domain. But it died too, halfway there, without a single user seeing it.
I didn't sleep that night. Not from guilt — from vertigo. How many hours of my life were buried in those repos? And what had I actually built with all that effort? The answer kept me up longer than the afternoon coffee.
The Real Problem Isn't Discipline
When we talk about abandoned projects, the conversation usually goes straight to a lack of discipline. "You have no consistency." "You give up too easily." "You need a better plan."
That's not true.
In those same four years, I learned TypeScript from scratch, Kubernetes to the point of certification, and enough networking to build a homelab that makes my electricity bill weep. I maintained regular open source contributions and published technical articles every two weeks without fail.
Discipline wasn't the problem.
The problem was what I was coding for.
Coding for Dopamine
Here's an uncomfortable confession: for years, I wasn't coding side projects to ship products. I was coding because it felt good.
The git init. The empty folder. The infinite possibilities. That moment when everything is perfect because nothing exists yet. No bugs. No angry customers. No architectural decisions to regret. Just pure potential.
I was addicted to that phase.
Starting a project is pure dopamine. Everything is new, everything is exciting, everything lies ahead. But maintaining a project — when you've seen the same code a thousand times, when the bug you're chasing refuses to be caught, when you realize the remaining 80% of the work is tedious — that doesn't generate dopamine. It generates cortisol.
And I, without realizing it, had become a start junkie.
Building Alone
The second pattern was more subtle.
All my side projects were secrets. Not by strategy — by embarrassment. "I'll show it when it's more polished." "It's still too rough." "I don't want people to think I'm a mess."
The result was predictable: I worked for weeks in complete isolation, with no feedback, no accountability, no one to tell me "what you're building serves no one" or "that feature that'll take you a month, no one will use it."
A project built in solitude is fragile. Any obstacle — a stubborn bug, a Sunday without motivation, a tweet that makes you doubt your idea — knocks it over. There's no one to hold you up.
And worst of all: when you abandon a secret project, literally nothing happens. The universe doesn't notice. That absence of consequences makes quitting the default option.
The Passive Income Fantasy
The third killer was premature monetization.
Every project I started came with an imaginary financial projection: "if I charge $29/month and get 200 customers, that's $5,800." I'd run numbers with zero anchor in reality while the product didn't have a single test user.
Even worse: the income expectation killed experimentation. I was no longer playing, exploring, learning. I was "investing time." And when something becomes an investment, pressure destroys it. Every hour without a return felt like a loss. Every day without launching was accumulated anxiety.
The irony: the projects I actually finished were the ones I started expecting nothing in return. No spreadsheet of projections. No monetization plan. Just the satisfaction of building something and seeing if it worked.
What Changed
It wasn't a productivity rule. It wasn't a habits system. It wasn't a bullet journal.
It was understanding three things:
First: finishing isn't binary. There's no "finished" as a final state. There's "good enough to ship." A project is ready when it solves a problem for someone who isn't you. Period. Not when it's polished. Not when it has every dreamed-up feature. When someone else can use it and get value from it.
Second: feedback is oxygen. Now I tell someone what I'm building the same day I create the repo. I don't wait for it to be "presentable." I show it when it's still ugly, when it still embarrasses me, when it's barely more than a functional wireframe. Because early feedback does two things: it validates that what I'm building makes sense AND it gives me the energy of knowing someone is waiting to see it finished.
Third: separate exploration from execution. Not every project needs to be finished. Some exist to learn a technology, to test a wild idea, to resolve a technical question. Those projects aren't failures — they're exercises. But if a project has the intention of reaching production, I treat it differently from day one: I define the minimum "done" and set a date. If it doesn't have a ship date, it's exploration. And that's fine. What's not fine is lying to myself.
Your Graveyard Isn't Your Enemy
Here's the part nobody says: those 23 projects weren't a loss.
Among the ruins of that graveyard are the foundations of everything I know. I learned Docker trying to containerize a SaaS I never launched. I learned JWT authentication building a dashboard no user ever saw. I learned WebSockets for a real-time chat that I used exactly by myself, testing it between two browser tabs.
Every dead project left me something. A pattern. A tool. A "this doesn't work that way" that saved me weeks on the next attempt.
The graveyard isn't the problem. The problem is convincing yourself that all your projects will end up there.
If you have 5, 10, or 30 abandoned repositories, you're not a bad developer. You're a developer who has explored. Who has been curious. Who has tried things. But maybe — just maybe — it's time for one of those attempts to cross the finish line.
Not because it's perfect. But because you've learned enough. Because it's time. Because the next commit can be Deploy v1.0.
And when that project is in production — ugly, incomplete, vulnerable, but ALIVE — you'll look back and the 23 corpses in the graveyard will look like what they really are: the stepping stones that brought you here.
Do you have a graveyard too? What's the project that hurt the most to abandon? Mine was a course platform that reached 87 commits. I still own the domain. Just in case.
Top comments (0)