Zombie Projects — Not Dead, Not Alive, Just Running

A zombie project is not dead, not alive, just running. The domain auto-renews, the server is up, the last commit was eight months ago.

"On pause" is a lie. Paused implies intention to resume. What you have is an abandoned startup with a heartbeat.

Zombies cost more than money. They drain mental bandwidth, guilt you into inaction, and block you from starting something new.

The sunk cost fallacy keeps them alive. You spent six months building it. You can't just let it die. Yes, you can — and you should.

The cure: audit every project. Ship it, sell it, open-source it, or kill it. No more "I'll get back to it."

Killing a zombie frees up the one resource you can't buy back: your attention. That attention is worth more than any half-dead side project.

You know the symptoms. The landing page still loads. The SSL certificate auto-renews. There might even be a user or two trickling in from some forgotten backlink. But nobody is home. No commits, no updates, no roadmap. The project exists in a limbo state — technically alive, functionally dead.

Graveyard projects are the indie builder's version of a body that forgot to stop breathing. They sit on your server, eating resources and bandwidth, while you pretend they're "on pause." They're not on pause. Paused implies intention to resume. What you have is an abandoned startup with a heartbeat.

The telltale signs are always the same: a GitHub repo with cobwebs, a Slack channel with the last message reading "will fix Monday," and a Stripe account that still charges $20/month for hosting nobody uses. The project isn't dormant — dormant things wake up. This thing is undead.

The psychology behind zombie projects is surprisingly simple: shutting something down feels like admitting failure. As long as the server runs, you haven't failed. You've just... not finished yet. There's a difference, right?

Wrong. The perpetual beta mindset and the zombie project share the same root — an inability to draw a line and say "this is done, and done means over." Every indie builder has at least one project they keep alive purely out of guilt. You spent six months on it. You told people about it. You bought the domain for three years.

But here's the uncomfortable truth: keeping a dead project alive costs more than killing it. Not just in hosting fees — in mental overhead. Every zombie project occupies a slot in your brain. It's one more thing on the list you'll never get to, one more tab you keep open, one more source of low-grade anxiety every time someone asks "so what happened with that thing?"

Let's do the math. A typical zombie project costs you:

• Hosting: $10–50/month for a server nobody visits
• Domain: $15–30/year for a name nobody types
• Mental bandwidth: Incalculable, but real — every zombie takes up space in your task list, your conscience, and your portfolio
• Reputation: That half-broken app with the 2023 copyright in the footer? People find it. It reflects on you.

Multiply that across two or three graveyard projects and you're bleeding resources into the void. The hosting costs alone could fund your next real project. The mental bandwidth could be the difference between shipping something new and staying stuck in maintenance mode for things nobody cares about — including you.

And then there's the opportunity cost. Every hour you spend "maybe I should update that thing" is an hour not spent building something that matters. Zombie projects don't just drain resources — they prevent new ones from being born.

Not every quiet project is a zombie. Some projects are genuinely dormant — seasonal tools, niche utilities that work fine without updates, side projects waiting for the right moment. The difference is intent and honesty.

A dormant project has a reason to exist and a trigger to resume. "I'll revisit this when the API they depend on ships v2" is dormant. "I'll get back to it eventually" is dead. If you can't name a specific condition under which you'd actively work on it again, it's not sleeping. It's a corpse.

Be honest with yourself. Open the repo. Look at the last commit date. Look at the issues. Look at the analytics. If the answer to "would I start this project today, knowing what I know now" is no — congratulations, you've identified a zombie. Now do something about it.

Shutting down a project is a skill, and most indie builders never learn it. Here's the protocol:

1. Archive, don't delete. Make the repo read-only. Push a final commit that says "archived." Keep the code — you might reuse pieces later.
2. Redirect or sunset the domain. Either point it to your main site or let it expire. Don't leave a broken landing page floating around the internet.
3. Notify users. If anyone actually uses it, give them notice. A simple "this project is shutting down on [date]" email is enough. Respect the people who gave you their time.
4. Kill the infrastructure. Cancel the hosting. Remove the CI/CD pipelines. Delete the monitoring alerts. Every piece of infrastructure is a thread tying you to something that no longer matters.
5. Write the postmortem. Not for anyone else — for you. What did you learn? What would you do differently? The project graveyard becomes a learning tool when you treat each dead project as a case study, not a shame.

Killing a project isn't failure. It's triage. You're reallocating resources from something that can't be saved to something that can.

Every experienced indie builder has a graveyard. The difference between a good builder and a stuck one isn't the number of dead projects — it's what they did with the bodies.

Your graveyard projects contain lessons you paid for in time, money, and emotional energy. The project that failed because you never validated the market? That's a lesson in startup idea validation. The one that died because you couldn't stop adding features? That's a lesson in scope. The one you abandoned because something shinier came along? That's a lesson in commitment.

Stop treating your project graveyard like a source of shame. Start treating it like a curriculum. Every dead project taught you something. If you can't name what it taught you, you haven't finished learning from it yet.

The best founders aren't the ones who never fail. They're the ones who fail fast, learn deliberately, and move on without dragging zombie projects behind them like chains.