Almost Launched: The Brutal Purgatory of Projects That Are Too Good to Kill and Not Good Enough to Ship

Somewhere on your team's shared drive — or buried in a Notion page nobody opens anymore — there's a project that almost made it. It passed the demo. It got the head nods. Someone said "we should really finish this" at least three separate times. And yet, there it sits. Not dead. Not alive. Just... existing in that liminal space between "proof of concept" and "thing real users can actually touch."

We call it the 80% problem, and it's quietly one of the most demoralizing experiences in digital product work.

Why 80% Feels Like the Finish Line (But Isn't)

Here's what makes this particular trap so insidious: the first 80% of any experimental project is genuinely exciting. You're solving hard problems, making creative decisions, proving the concept. Progress is fast and visible. Then you hit that last stretch — the edge cases, the error handling, the accessibility work, the security review, the stuff that doesn't show up in a demo but absolutely shows up when something breaks in production — and suddenly the momentum evaporates.

The prototype still works in the controlled conditions you built it for. It's impressive enough that no one wants to officially call it dead. But it's not ready for real-world load, real users, or the kind of scrutiny that comes with actually shipping. So it just... waits.

For weeks. Then months. Then you're onboarding a new engineer and you're explaining what that thing is and why it exists and even you don't fully remember anymore.

The Hidden Cost Nobody Puts on a Roadmap

Organizations are pretty good at tracking the cost of building things. They're terrible at tracking the cost of almost building things.

Every project stuck in this purgatory carries real overhead. Someone has to maintain the environment it runs in. Someone has to answer questions about it when stakeholders ask for status updates. It occupies mental real estate — your team knows it's there, and that ambient awareness creates a low-grade guilt that's hard to quantify but very easy to feel. Engineers who built it feel a sense of unfinished business. Leadership keeps half-expecting it to magically cross the finish line on its own.

Meanwhile, the codebase ages. Dependencies drift. The person who understood the weird workaround in module three got promoted and moved to a different team. The window for this thing to matter might be closing, and nobody's making a call.

The Three Paths Nobody Wants to Choose Between

When a prototype stalls out in this zone, there are really only three honest options — and none of them feel great in the moment.

Push it across the finish line. This means actually resourcing the project like you mean it. Dedicated time, a clear owner, a real definition of "done" that includes production-readiness — not demo-readiness. This is the right call when the underlying problem is still urgent, the market timing still makes sense, and the prototype's core architecture can survive the hardening process without a complete rewrite.

Rebuild it from scratch. Sometimes the prototype proved the idea but the implementation was never meant to scale. Rebuilding isn't failure — it's actually a sign the experiment worked. You learned what you needed to learn. Now you build the real thing with that knowledge baked in from the start. The mistake is trying to polish a prototype into production readiness when its foundations were never meant to hold that weight.

Retire it with intention. This one's the hardest for teams to do well, but it might be the most valuable. Officially closing out a project — documenting what worked, what didn't, what you'd do differently — turns a stalled experiment into institutional knowledge. It frees up the mental space your team was using to feel vaguely bad about it. And it gives the engineers who built it actual closure instead of the slow fade of just... never talking about it again.

Building the Criteria Before You're Emotional About It

The real fix isn't about any one project. It's about having a framework in place before your next prototype hits that 80% wall, so the decision doesn't get made by default or avoidance.

A few questions worth building into your team's process:

Is the problem this solves still the problem we're trying to solve? Markets shift. Priorities change. A prototype that was urgent eight months ago might be solving a problem that no longer exists — or one that a third-party tool now handles better than you ever could.

What would "done" actually require? Get specific. Write it down. If the list of remaining work is longer than what's already been built, that's data. If it's genuinely achievable in a reasonable sprint with real resources, that's different data.

Who owns this? A project without a clear owner is a project that will never get decided. Ownership means someone is accountable for making one of the three calls above — not for keeping it alive indefinitely.

What's the cost of waiting another quarter? Sometimes waiting is the right move. But it should be an active decision with a revisit date, not a passive drift into irrelevance.

Giving Experiments a Dignified Exit

There's a cultural piece here that's easy to overlook. Teams that are good at killing projects — or at least decisively categorizing them — tend to be teams where experimentation feels safe. When engineers know that a project can be officially retired without it being treated as a failure, they're more willing to take creative risks in the first place.

The prototype graveyard only becomes a problem when it's invisible. Projects pile up, nobody talks about them, and the whole thing starts to feel like a monument to institutional indecision. But if you've got a real process for reviewing experimental work — regular triage, honest conversations, clear criteria — that graveyard becomes something closer to a research archive. A place where the work is documented, the lessons are captured, and the team can actually move forward.

The goal isn't to ship everything. It's to make a real decision about everything. That distinction is smaller than it sounds, and it changes everything about how your team approaches the next experiment.