18/05/2026
My Graveyard Folder has 22 dead projects (and two in critical care).
I have a folder on my computer that stores all my apps; the live, the dead, and a couple that are on life support.. I recently counted the âdeceasedâ: exactly 22 abandoned apps created over approximately the last 2 years.
Amongst the dead; an augmented reality mobile app for installation engineers, a version of AirBnB for dogs and cats looking for accommodation, and a web app for Pickleball players. There was even a massively complex multi-tenant cloud based ERP system that I spent weeks working on before deciding that I posed little threat to SAP.
Hundreds, if not thousands, of hours wasted. Why did they all die before seeing the light of day? It was not a lack of time. It was not a lack of motivation. And it certainly wasnât a lack of ambition or imagination.
The harsh reality:
Most developers do not fail because of a lack of technical skill. They fail because they secretly enjoy the dopamine rush of starting a new project more than the grind of getting it finished.
Here is the exact play book that killed my 22 projects, and the change that helped me break the cycle.
1. The "Perfect Stack" Trap
As developers, we love shiny new tools. When starting a project, the first instinct is to try that new database, or the latest âgame changerâ framework using the hottest new technology.
I have spent an entire weekend before now configuring a complex highly scalable AWS cloud environment, with mobile and web front ends using the latest UI tooling and a noSQL DB. All deployed with a CI/CD pipeline âthat was to die forâ. Technically exquisite infrastructure but by Monday morning I still had not actually written any business logic for the app. By Tuesday I lost interestâŠ
If you want to actually finish a project, use boring technology. Pick the stack you know best, even if it feels (and actually is) outdated.
2. Optimising for Phantom Users
For my multi-tenant ERP system I spent a lot of time setting up complex cloud solutions, particularly for database scalability and performance. I was paranoid that if hundreds of organisations signed up, there could easily be thousands of concurrent users in the first week or so. It seemed to me that ensuring fast response times would be key to them becoming advocates and providing positive case studies. I had load balancers coming out of places that load balancers should never be, and a network architecture that would have supported the BBC on a heavy news day. And letâs not even talk about the database architecture. However, absolute âcricketsâ.
We love to over-engineer. We worry about how our database will handle massive traffic, so we design complex micro-services. But the brutal reality:
Your biggest threat is not the server crashing. Your biggest threat is that nobody will ever visit your app.
Stop building for problems you do not have yet. A simple database is fine. You can always optimise later when (and ifâŠ) the app actually gets traction.
3. Feature Creep is a Disease
It starts innocently. You are building a simple to-do list, and you think, "It would be cool if users could upload custom profile pictures.â Suddenly, you are reading AWS S3 documentation for five hours instead of finishing the core business logic.
Engineering exciting features is fun, but they are âcostlyâ to build. Every unnecessary feature delays the launch. The best way to finish an app is to ruthlessly cut features and focus on the absolute minimum viable product. If a feature does not directly solve the core problem, it gets deleted.
4. The Fear of Shipping
Writing code is safe. Your development environment does not judge you. But launching a project means real people might see it, find bugs, or worse (and more likely)âignore you and your app completely.
A lot of indy projects are abandoned between 90 and 99 percent because the developer is secretly afraid of pressing the go live button. We hide behind the excuse of "it just needs a little more polishâ.
A buggy, ugly app that is live on the internet is infinitely more valuable than a perfect app sitting on local hard drive.
The 14 Day / ÂŁ0 Rule
To break this curse, I set myself a simple rule: I have to launch a working, ugly, basic prototype within a fortnight and at zero cost.
If it takes longer than two weeks to get the most basic iteration of the single highest value core feature live, then the scope is too big (for me as an independent solo developer). Coupled to this, other than my time, there should not be any reason to spend any money. This simple mindset is one of the biggest reasons I finally started shipping real apps again instead of adding to the graveyard.
How do you do it?
Iâm certain that I am not the only developer with a âgraveyard folderâ on my machine. And Iâm equally sure that I am not the only person to have found a cure.
How did you break the curse? Keen to hear how others have broken the doom cycle, but even more interested to hear about your weirdest abandoned project and what was the real reason you stopped working on it? (It will make me feel better about some of mine!)
Let me know in the comments.
