I recently opened my GitHub account and filtered by private repositories. I actually counted them: exactly 27 abandoned side projects created over ...
For further actions, you may consider blocking this person and/or reporting abuse
For me, I just have projects that I am certainly proud of, but I just don't share it since there are projects I made that are better than the previous one. It's normal for me since I know I am growing in some way.
When you mention "Most developers do not fail because of a lack of skill. They fail because they secretly enjoy the dopamine rush of starting a new project more than the grind of finishing it.". This is really common and it is something that needs to be address more. A lot of people start off projects since they see new things like you mention and than fail because of the project being too ambitious or that it has a learning curve.
Great work and thanks for sharing :D
That is such a healthy mindset! Looking back at your older projects and realizing you have outgrown them is the ultimate proof that you are improving.
You also completely nailed it with the "too ambitious" point. When we combine a massive project scope with a brand-new framework that has a steep learning curve, it is almost a guaranteed recipe for burnout. The initial dopamine wears off right when the real friction begins!
Thank you so much for reading and adding your perspective! What is the "boring" tech stack you usually stick to when you actually want to finish a project?
Back then, I stuck with Vanilla HTML, CSS, JS since I was a beginner. Now focusing on Next.js and that would be my niche. Don't really have a "boring" stack since I didn't really expand further yet, but I shall see in the upcoming future!
I have a similar problem with my writing projects 🫣 The fear of shipping, or rather publishing in my case, feels way too real. And it's much more exciting to start a new story than to develop and bring to publishing the more mature one. However, about:
... I know that this way of thinking keeps sneaking in. But maybe instead of thinking that these hours are wasted, it's better to think you learnt something during this time?
That’s a really good perspective, and honestly something I’m still trying to internalize. As developers , we’re often way harsher on our unfinished work than we should be.
You’re right that not all of those hours were truly wasted. I learned new tools, made bad architectural decisions I’d never repeat, and understood my own patterns better. I think the “wasted” feeling comes more from knowing some of those projects died from avoidance rather than genuine exploration.
And the publishing fear you mentioned feels incredibly relatable. Starting something new gives instant excitement, while finishing means facing judgment. Different medium, same psychology 😅
You can still resurrect some of the projects that you gave up on as a form of avoidance, can't you?
That’s a fair question 😄 I probably could resurrect some of them, and a few still have genuinely good ideas behind them.
The bigger challenge is figuring out whether I want to revive them because they’re still worth building, or just because I feel guilty for abandoning them 😅
Have you ever gone back to an old writing project and found it was actually better than you remembered?
Yes, some time ago I went back to two projects that were the most promising and also the most developed. Both are materials for quite a good story, but I abandoned them because of a lack of self-confidence. I keep telling myself that I will come back to them once I'm a much better writer, but I see the flaws of this logic 🙈
Anyway, compared to my old writing, I see that I have developed a lot! I've once heard a very wise sentence, saying that you shouldn't compare yourself to others, just to your old self. And I agree 💯
That logic is so relatable 😅 “I’ll come back when I’m better” sounds wise at first, but sometimes it’s just self-doubt wearing a very rational disguise.
And I really love that comparison mindset. Measuring yourself against your old self feels much healthier than chasing someone else’s chapter 20 while you’re on chapter 3.
Honestly, the fact that you can revisit those stories and clearly see your growth probably means you’re already far more ready than you think 🙈
counted mine last year - it was 40. what fixed it wasn’t discipline, it was making each project shippable in under a week. long cycles kill more motivation than the dopamine high does.
40 😅 okay, I suddenly feel less alone 😂
And that’s a really interesting point. Framing it as a cycle-length problem instead of a discipline problem makes a lot of sense. A one-week shipping target forces you to stay focused on what actually matters.
Out of curiosity, did that change mostly improve your completion rate, or did it also make the projects themselves better?
honestly yes - completion rate shot up just because the scope ceiling forces you to cut everything optional early. first few weeks felt weird, now that's just how I work
That actually makes a lot of sense. Cutting optional complexity early is probably where many of us fail 😅 What feels restrictive at first ends up becoming a really healthy default.
yeah and the interesting flip is you stop fighting the scope ceiling pretty quickly once you realize it's doing the prioritization for you. the one-week clock is basically a forcing function for the conversation you'd otherwise delay forever
That’s such a sharp way to frame it. “A forcing function for the conversation you’d otherwise delay forever” is painfully accurate 😅
A lot of us probably don’t have a project execution problem, we have a decision avoidance problem disguised as perfectionism 😂
I know that feeling! 27 projects in 3 years isn't much. I've already got 10 in 4 months. You've described why this happens so accurately, and it's disappointing that half the projects end up in the recycle bin, not because they're bad, but because they're boring. Great article.
10 in 4 months 😄 you might beat my record soon.
And that point about projects becoming boring rather than being bad is painfully true. I think that’s where real discipline starts, when the novelty disappears but the work still matters.
Out of those 10, did any of them feel worth revisiting later?
I'm afraid all these projects are doomed to two fates: forgotten corners of Github and Recycle bin. 🤒
😂 That is the classic developer graveyard fate.
But honestly, I like to think some of them are less “dead” and more “hibernating until future me suddenly gets a weird burst of motivation at 2 AM” 😄
Be honest, if you had to save just one of those 10, which one gets rescued?
i have project to create a waste trade for money, i started for my school project as we have a waste bank that collect some type of waste and then sell it to a collector. it to encourage student to be aware of their environment, but since i left the school the project been stuck... no drive anymore
That’s actually a genuinely meaningful project. Turning waste into something valuable while building environmental awareness is a great idea.
I think a lot of projects don’t die because the idea was weak, but because the context that gave them momentum changed. Leaving the school probably took away the ecosystem that made it work.
Do you think this is something that could be restarted in a different form outside the school?
actually in my city there are communities that do the same, but mostly not documented well enough and mainly use spreadsheet as accounting tools. some even just use physical bank book. many of them are illiterate enough to use system because it start in country side and slum. also another point is people who are proactive to do this mostly are mid to elderly.
but the potential for community project is high
That makes this even more interesting. The challenge clearly isn’t the lack of a real problem, it’s designing something that fits the people actually using it.
A lot of projects fail because we build for the ideal user instead of the real environment. Community-driven systems like this need simplicity more than sophistication.
The potential here sounds genuinely huge.
There is one. The project was an inspiration from WesBos's JavaScript30 course. It was titled Pixel Dust (from Pixie Dust). My core idea was to build a web app that allows users to mix magic stats and after pressing save, the wand will shoot a Harry Potter-like magic blast which varies depending on the settings the user configured.
When I was making it, I realized it was too tall for a task, (I was also new to React back then). I wanted it to have multiple combinations of spells and even secret spells. Sadly, the project still rests today in a public repo. This taught me a lesson. Never start what you can't finish.
So far, that's the only project I have that I didn't finish. Hopefully it will not be followed by another. (still hoping to revive my first dead project tho)
Pixel Dust is such a fun project name 😄 And honestly, this feels like the exact trap many of us fall into: a simple idea that slowly evolves into “what if it also did this?” until the scope quietly explodes 😂
I’m not sure the lesson is “never start what you can’t finish” though. Sometimes we only discover what’s too big by starting. That’s still valuable.
Also, having only one unfinished project after this entire discussion is honestly impressive 😄
The struggle is real. We bite off huge chunks to test our limits, and while the skill level goes up, the 'unfinished' folder grows even faster. Sometimes the learning is the real project, even if the repo stays dead.
Learning is cool, but finishing is a different kind of muscle.
“Finishing is a different kind of muscle” — that’s such a strong way to put it.
I think a lot of us accidentally train the learning muscle constantly while neglecting the shipping muscle 😅 Both matter, but they build very different habits.
Have you found anything that helped you get better at the finishing side, not just the learning side?
I am still figuring it out honestly, but treating the repo as a warehouse rather than a graveyard is a start — changes how you see what's worth returning to.
That “warehouse rather than a graveyard” mindset is honestly brilliant. It turns unfinished projects from symbols of failure into stored experience, ideas, and building blocks. I really like that perspective.
This article got me 😂
Not surprisingly, I also have a lot of abandoned side projects and all of them have never been released at all. I sometimes look around them thinking 'I should've finished at least one of them..'.
For me, the biggest obstacle to finish side projects is that I think too much before even I start the projects. I keep asking my self questions like 'Is this idea really profitable?', 'Would people really need this?', etc. I think sometimes I should just give it a shot without overthinking.
Thank you for the insight!
This is very relatable 😄 Sometimes we kill projects before they even get the chance to fail because we try to validate every possible outcome upfront.
That “is this profitable / do people need this?” loop sounds smart, but it can quietly become a form of procrastination 😅 Sometimes shipping a small imperfect version teaches more than weeks of thinking.
Glad the article resonated with you. Out of curiosity, have you ever had a project that you almost overthought to death, but looking back, you wish you had just shipped anyway?
Yes. And I still sometimes regret it🥲
About few years ago I was building a small web app that was about a game I used to play. The app was about showing users' character's rare items acquirement history.
It was really simple to build so I could've finished it, yet I abandoned it because I thought about too many things at once. Honestly, I just assumed that the users would not be attracted to my app.
But I soon realized that I was completely wrong because another user made almost the same app and it got a lot of other users' attentions😂
Oof 😅 that is painfully the perfect example of overthinking stealing a perfectly viable project 😂
The worst part is not that the idea failed, it’s realizing the assumption was wrong and someone else proved it by simply shipping. I think a lot of us have at least one story like that 🥲
So true! Let's move faster and think simpler for our projects😁 Thank you for sharing your insights!
It seems you mix or confuse startup launches with github repos. Having 27 or 270 abandoned projects in github is not a failure. It's experience, grit, and audit trail. If you consider success a project that turns into a marketable and profitable product, you are talking about a startup, not a github repo.
I have infinite abandoned projects as you say, but they build up to my latest contributions in top tier quantum repos from Google, IBM, Pennylane, all the way to unique AI frameworks used by people in OpenAI and Google.
Coming here, wouldn't be possible, but launching a repo in 48h with non github history. That's a lovable user's github that is an insta block for recruiters or investors.
Do not take your work and effort lightly. You did all that just to come here where you are today, and your steps tomorrow will be stepping on that graveyard as you name it.
That’s a really thoughtful perspective, and I actually agree with a lot of it.
I definitely didn’t mean abandoned repos as “worthless failures.” A lot of them taught me exactly what I know now. The post was more about the behavioral patterns behind why projects stall, especially when the goal was to actually ship something usable, not just explore.
I really like your “audit trail” framing though. That’s a much healthier way to look at the graveyard.
Good luck on your next projects <3
I try to build a microservice for the future users in my dreams instead of getting started with a monolith, I just feel I'm drawn to the concept, building a Ferrari rather than getting started with a simple bicycle
This is painfully relatable 😄 Building for imaginary scale is such a seductive trap because it feels ambitious and smart.
The Ferrari vs bicycle analogy is perfect. A lot of us try to optimize for future users who may never exist instead of solving one real problem first.
It’s definitely developer syndrome at this point. 😭 Do you happen to have a cure for this, or do I just keep writing Docker files for an app with zero user
😂 My current “cure” is forcing myself to earn the Docker file by first building something that one real user (even just me) can actually use.
Infrastructure after usefulness, not before. Easier said than done, of course 😅
Easier said than done... 🤣🤣🤣🤣 But I really appreciate team managers at this point, they’re really helping devs get out of their own heads and put something out there.
I think building something that you actually want to use is much better project since it will solve a problem you have at the end of it, so there is an incentive there, and for learning I rather do a real scrappy project but with clear steps and an end
For example I recently built wc clone with Rust, its not a 1-1 match with GNU wc, obviously, but goal was never that, it was to learn how to handle reading files efficiently, handling reading from a file or stdin, learning about UTF-8 and deciding on buffer size, discovering other techniques like SIMD, mmap crate, etc. etc.. .....and so on
I think I am better off doing a small buggy scrappy project if it teaches me something more fundamental about computers and the language itself, along with compromises and balanced decision making while building such tools.
I would even say its okay to ship slightly buggy projects , as long as you are working on it consistently, coz once you lose momentum, you will lose interest too
This is such a solid perspective. I really like the distinction between “learning projects” and “trying to build the perfect thing” 😄 Your Rust wc clone example is exactly the kind of scrappy-but-valuable project that teaches fundamentals instead of just framework glue.
And I strongly agree with the momentum point. Slightly buggy but consistently evolving often beats “perfect but never shipped” 😅
Building something you personally want to use also feels like a built-in antidote to abandonment. Have you found that your personal-use projects survive longer than purely experimental ones?
Yes, I have abandoned some projects that were basically some cookie cutter projects, like building a chat app with web3, very interesting concept, I was only doing it for the sake of it though, when it came down to deploying it, it was too tough and I gave up, vs my blog, I have framed it as a way to share my thoughts and a personal space to rant / allow my raw thoughts to be put there, it did not even look pretty on mobiles, when I first shipped it, code was overflowing bounds for mobile, but that is why since its so close to what I want to really do , I fixed it for mobile view !
That’s actually the perfect example of the difference. The web3 chat app was interesting, but your blog was personally meaningful, so imperfect shipping didn’t stop you from improving it.
I think that’s a huge insight. We tolerate rough edges much more when the project genuinely matters to us.
This hits way too close to home. I think most of us have a "Graveyard" folder we try to ignore.
That "Perfect Stack" trap is the ultimate procrastinator's move. It's so easy to feel productive while tweaking config files for six hours, but you're really just avoiding the actual logic.
The 48-hour rule is a massive reality check. Shipping an ugly, working app is infinitely better than a "perfect" one that stays on localhost forever. I once wasted weeks over-engineering a backend for an app only I was going to use, then quit before I even built the UI.
Solid advice, Tahosin. Definitely the kick I needed to just ship my current project.
Haha, building a massive backend for an app with literally 1 user (yourself) is a classic right of passage! We have all been there. 😂
"Productive procrastination" is so dangerous because tweaking config files actually feels like real work until you realize you built a mansion with no doors.
So glad the 48-hour rule resonated with you! What is the current project you are trying to ship right now? Drop a link here as soon as you hit deploy even if it's completely ugly!
The "Perfect Stack" Trap is real, and it's very relatable. It's tempting to dive into shiny new tools and stack complexities, but it often leads to incomplete projects. The idea of using "boring" tech might seem counterintuitive, but it's effective for actually getting things done. For interview prep, I've been using LeetCode for DSA and prachub.com for system design. They cover the follow-up questions that appear in actual rounds, which can sometimes feel as elusive as finishing a side project.
The “perfect stack” trap gets so many of us because it feels like progress 😅 Choosing boring, familiar tech rarely feels exciting, but it dramatically increases the odds of actually shipping.
That last comparison made me laugh, sometimes follow-up interview questions and unfinished side projects really do trigger the same kind of existential crisis.
I really agree. It resolves the question of why does the heart that started beating at the end die so much.
Exactly 😅 I think that’s the painful part. The project itself often doesn’t “die” because the idea was bad. It dies because the emotional state that created it fades.
Starting gives excitement, possibility, and instant momentum. Finishing asks for patience, consistency, and a willingness to be judged.
Have you found any way to keep that initial energy alive long enough to actually ship?
The "Perfect Stack Trap" hits hardest for me. I'd add a fifth pattern though: starting so many things in parallel that you lose track of which ones you've actually abandoned vs. which ones are paused vs. which ones you forgot existed.
AI made this worse for me. Easier to spin up a new repo with Claude than to look back at the 8 I already have. The dopamine isn't just from "new project"; it's from "fresh context, no baggage". Existing half-built things carry shame; new repos don't.
The 48-hour rule helps for one project at a time. The harder discipline is auditing the graveyard before starting the next one.
Wrote about my approach to the audit problem here if useful: The markdown convention I built for it
This is a really sharp addition. “Fresh context, no baggage” explains the psychology way too well.
And honestly, AI definitely lowers the friction to start, but not necessarily the discipline to finish. The idea of auditing the graveyard before opening a new repo is a genuinely useful counterbalance.
Exactly. The friction to start dropped to near-zero, but the friction to finish and the friction to quit honestly both went up.
Your 48-hour rule and a graveyard audit are different sides of the same discipline: forcing decisions instead of leaving things open.
This is what I call the trap of 'phantom complexity'. Many developers chase the dopamine of new stacks but lose sight of actual system determinism. In my 'Walking & Coding' philosophy, a minimalist prototype running in production is infinitely superior to a perfect architecture that never ships. Stop over-engineering and start reclaiming your delivery sovereignty.
‘Phantom complexity’ is a painfully accurate term. I think a lot of us fall into that trap because building feels productive even when nothing ships. Your point about delivery sovereignty hits hard. In my case, many of those dead projects were me chasing the excitement of architecture instead of solving one small real problem well. Appreciate this perspective
This hit hard. Every developer has a GitHub graveyard, but few talk honestly about why projects die. The real win is not having zero failed projects, it’s learning faster with every unfinished one. Great read 👏
"Learning faster with every unfinished one" — that is such a brilliant way to look at it! I completely agree. Each dead project in the graveyard is basically a stepping stone that taught us a new framework or a hard architectural lesson.
Thank you so much for reading and for the kind words! Out of curiosity, what is the most valuable lesson one of your own unfinished projects taught you?
One of mine taught me that premature optimization can kill momentum. I kept rebuilding the backend instead of shipping features. The project died, but the lesson stuck 😂
😂 That is painfully relatable. “Just one more backend rewrite” has probably killed more side projects than actual bugs.
It’s wild how productive premature optimization feels while quietly destroying momentum 😅 Did you ever end up applying that lesson successfully in a later project?
Draw a finish line before you write a single line of code. Know where "this project will be a success if" can be drawn (or conversely "this project will not be a success if"). Specific and simple conditions for when you can feel comfortable with moving onto the next effort. A poor second/consolation alternative is, have a metric where you can measure specific progress and then draw a minimal finish line (eg at 80% of something).
This is such practical advice. A lot of abandoned projects probably die because the finish line keeps moving 😅 Defining “success” before writing code feels like a simple but powerful habit.
I especially like the 80% idea, because perfectionism quietly kills momentum.
This was a great read. The honesty here hits because so many of us have our own quiet pile of abandoned repos. Your breakdown of why those projects died feels real and relatable, and it reminds me that unfinished work is still part of the learning curve. Thanks for putting this into words.
I have to say all 4 reasons resonate so deeply, it's kind of embarrassing. That 48-hour rule is gold, I will use it for our next project 🫣. As the legendary Taiichi Ohno (Toyota manager) once said: "Better 80% now than 100% never..."
That quote is perfect for this conversation 😄 “80% now than 100% never” is basically the antidote to half my GitHub graveyard.
And honestly, the embarrassing part is exactly why I wrote the post. So many of us quietly deal with the same patterns and assume we’re the only ones 😅
Now I’m curious, what kind of project are you planning to test the 48-hour rule on?
Mykola's "one-week shipping target as scope ceiling" thread maps to something we keep seeing on the writing side, where the parallel of the 27-dead-projects graveyard is the manuscript that's been "almost ready to record" for two years. The fix that's been working for the writers we work with at AudioProducer.ai is treating one chapter as the whole unit: render it to audio this weekend, even with three wrong voice assignments and a placeholder narrator, and ship that as the finished thing. The chapter-by-chapter pipeline turns the audiobook from a one-year shipping target into a sequence of weekend deliverables, and the writer gets to feel the "shipped, ugly, real" thing Tahosin describes thirty times per book instead of once. Ekong's "warehouse not a graveyard" reframe is also the right shape here: the rough audio drafts aren't dead, they're stored experience that catches structural problems in the manuscript that prose review never surfaces (pacing collapses on chapters that read fine on the page; wrong narrator personality on a POV character). The shipping muscle and the manuscript-quality muscle turn out to be the same muscle once the deliverable is audio rather than text.
This is a really thoughtful perspective. I love how you translated the same pattern into a completely different creative domain.
“Shipped, ugly, real” in smaller repeatable units feels like such a practical antidote to perfection paralysis. And that point about rough outputs revealing problems you’d never catch in the original medium is especially interesting.
Really like this framing. It makes shipping feel less like a final event and more like an ongoing feedback loop.
The 48-hour rule hit me hard. I have a private repo called "super-app" that I started 8 months ago. Spent the first two weeks just setting up the folder structure and deciding between Prisma and Drizzle. Never wrote a single feature. The perfect stack trap is real. I think we convince ourselves that infrastructure work counts as progress but it's just procrastination with a better excuse. The point about fear of shipping is the most honest thing I've read about side projects. It's not laziness. It's just easier to stay in the safe zone where nobody can judge the work yet. Starting the 48-hour rule this weekend. Let's see what actually ships.
“Procrastination with a better excuse” is painfully accurate. Spending weeks on setup while shipping nothing is way too relatable.
Love that you’re trying the 48-hour rule this weekend. Hope
super-appfinally gets its first real feature 🙂I completely agree with this! Will have to change my mindset a bit in building and deploying even smaller apps.
I've been building an asteroid tracker app in order to learn the full-stack development cycle, but I've spent over a few days at it, partially because I became a bit lazy after the first day or two, but also because I thought too much about the "final product" than a MVP. Even if I'm learning something new, I'll use this mindset to speed up my learning process. I'll focus on the real learning goal (basic full-stack) over the "bonuses/practice sets" (features).
That’s a really solid mindset shift. Focusing on the actual learning goal instead of the imagined final product is exactly where many of us get stuck.
An asteroid tracker is actually a perfect project for that too, clear scope, real full-stack practice, and plenty of optional features to intentionally ignore at first. Hope you get that MVP shipped first.
This hits close. I’ve been through this exact cycle — started exploring Hutter Prize compression, went through 30 different architectures over months (range coders, PAQ variants, neural predictors, bio-inspired structures). None reached the target.
At some point I stopped chasing the original goal and asked a different question. That pivot became ACEAPEX — a parallel LZ77 decoder that ended up in lzbench. Not what I set out to build. But it shipped.
The graveyard wasn’t wasted. It was the research log.
“The graveyard wasn’t wasted. It was the research log.” That’s such a strong way to frame it.
I also really like the part where success came from changing the question instead of stubbornly forcing the original goal. Not the destination you planned, but still something real that shipped. That’s a great outcome.
"If you want to actually finish a project, you have to use boring technology. Pick the stack you know best, even if it feels outdated."
I really resonate with this point. It does help reduce cognitive overload.
Exactly. Sometimes the biggest productivity boost is simply removing unnecessary decisions. Familiar tech may feel less exciting, but it leaves more mental energy for actually building the thing.
Yes, I am about to try to get some users for my app now… scary and uncomfortable… wish me luck 😄
That scary and uncomfortable feeling usually means you’re at the exact part that actually matters 😄 Wishing you lots of luck. Shipping is one thing, putting it in front of real users is a whole different level of courage.
Thanks! We are all here to learn... It won't be easy but I am sure it will be a good experience :)
Nice point. You're not alone 😃 Who doesn’t have unfinished things on github? We often judge ourselves and try too hard to be perfect. But it doesn’t have to be perfect, right?
The other day I heard someone say: ‘Everybody is a starter now. AI boosts beginners, but almost no one finishes things.’ It’s a bit sad, but also true i guess.
Also "the 48-Hour Rule" sounds applicable,I should try it
Great breakdown. I've been working with this for a while and still learned something new. Well explained and actionable.
As an intermediate, your post helped me a lot.
Also, I'm from bangladesh. And I would be more than happy if you give me some of your valuable time to talk to you.
That genuinely means a lot. I’m really happy the post helped you 😄 And always nice to meet a fellow Bangladeshi here.
I’m not some expert with all the answers, but I’d be happy to chat if I can be helpful. Feel free to reach out through DM 🙂
I would be happy to. Here is my facebook:
facebook.com/ahmed.didat.salat/
also, I will send email if possible.
Thank you for your valuable time, it means a lot to me.
I once spent 2 weeks building a “scalable” architecture for a side project that never got a single user.
The loading spinner had better uptime than the actual app idea.