Build It, Ship It, Kill It: The Case for Giving Every Experiment an Expiration Date

There's a particular kind of project that haunts every dev team. It's not the one that crashed and burned spectacularly — those you actually learn from. It's the one that kind of worked. The experiment that generated just enough interest to survive the first quarterly review, just enough usage to justify a second sprint, just enough internal momentum to stick around long after anyone could explain why it still existed.

We call them zombie features. And if you've worked on any kind of digital product for more than a few years, you've fed one.

The fix isn't better post-mortems or stricter prioritization frameworks, though those help. The fix is simpler and a little counterintuitive: decide when the experiment ends before it begins.

Why Smart Teams Are Scheduling Their Own Sunsets

At Konkreet Labs, we think a lot about what separates teams that consistently ship innovative work from teams that spend half their energy maintaining the digital equivalent of a storage unit — full of stuff nobody uses but nobody wants to throw out.

The answer, surprisingly often, comes down to how they handle endings.

Teams that innovate at a high clip tend to treat experiments like timed sprints, not open-ended commitments. They set a kill date upfront — sometimes 30 days, sometimes a quarter, sometimes tied to a specific milestone — and they honor it. If the experiment earns an extension, it has to earn it, with evidence.

This isn't pessimism. It's operational discipline. A predetermined end date changes the entire psychology of a project. Suddenly everyone on the team knows exactly what they're signing up for. Suddenly the experiment has stakes. And suddenly, when the date arrives, you have a forcing function for an honest conversation that might otherwise never happen.

The Real Cost of Experiments That Never Formally Die

Let's talk about what zombie features actually cost you, because it's more than server bills.

First, there's the cognitive load. Every unresolved project sitting in your backlog is a small, persistent drain on your team's mental bandwidth. It shows up in planning meetings as a question nobody wants to ask out loud: are we still doing that thing? It shows up in onboarding when a new developer asks what a certain module does and nobody can give a clean answer.

Second, there's the maintenance tax. Even a dormant feature requires upkeep. Dependency updates, security patches, compatibility fixes every time you upgrade your core stack — these aren't free. Multiply that across five or ten half-alive experiments and you've got a meaningful chunk of engineering hours disappearing into the void every month.

Third — and this one stings — there's the opportunity cost. Every hour spent propping up something that should have been killed is an hour not spent building something new. For teams trying to move fast and stay experimental, that math gets brutal fast.

How to Build a Kill Switch That Actually Gets Used

Setting a sunset date is easy. Making sure your team actually respects it when the moment comes is the harder part. Here's what tends to work.

Make the criteria explicit from the start. A kill date without success criteria is just a calendar event. Define upfront what "success" looks like for this experiment. Is it a certain number of active users? A specific engagement metric? A technical proof-of-concept that meets a defined performance threshold? Write it down. Make it visible. This turns the end-of-experiment review from a vibe check into an actual evaluation.

Separate the retrospective from the decision. When the kill date arrives, run two separate conversations. The first is the go/no-go call — does this experiment meet the criteria to move forward? The second is the retrospective — what did we learn regardless of the outcome? Mixing these tends to muddy both. Teams get defensive about the decision when they know the retrospective is coming, and they rush the retrospective when they're still processing the decision.

Celebrate the kill. This sounds weird, but it matters. If shutting down a project feels like failure, your team will resist doing it. If shutting down a project is treated as a deliberate, successful execution of a plan, it becomes something to feel good about. Some of the best innovation cultures we've seen have a literal ritual around this — a Slack message, a quick team shoutout, something that marks the moment as intentional rather than shameful.

Archive, don't delete. The code, the learnings, the data — all of it should live somewhere accessible. Not in active rotation, not on the roadmap, but findable. You'd be surprised how often a killed experiment becomes the foundation for something that ships two years later, once the timing or the technology catches up.

The Counterintuitive Truth About Commitment

Here's the thing that takes a while to internalize: giving a project an expiration date isn't a sign that you don't believe in it. It's a sign that you take it seriously enough to hold it accountable.

Open-ended experiments are actually a form of low commitment dressed up as ambition. They let everyone avoid the hard conversation indefinitely. A project with a kill date demands that everyone involved show up with intention — because the clock is running, and when it stops, you're going to have to say something true about what happened.

That kind of honesty is what keeps an innovation pipeline healthy. It's what lets teams move from one experiment to the next without dragging the weight of unresolved projects behind them.

Knowing When to Override the Clock

None of this means kill dates are sacred. Sometimes an experiment genuinely surprises you. Sometimes the data comes in stronger than expected, or a use case emerges that nobody anticipated, or the market shifts in a way that makes something suddenly relevant that wasn't before.

When that happens, extend the timeline — but do it deliberately. Make a conscious decision, with updated criteria, a new end date, and renewed buy-in from the team. Don't just let the project drift forward because nobody pushed back. The discipline isn't in never extending; it's in never defaulting.

The goal isn't to kill things for the sake of killing them. The goal is to make sure every experiment that stays alive is staying alive because someone decided it should — not because everyone was too busy to decide it shouldn't.

The Lab Mindset in Practice

Real experimental culture isn't about having a lot of projects running at once. It's about having a high throughput of completed experiments — things that were tried, evaluated, and either graduated or ended with intention.

Building in expiration dates is how you get there. It's how you keep your team's energy focused, your codebase clean, and your retrospectives honest. It's how you build a culture where shipping fast and learning fast aren't just slogans on a wall.

Give your next experiment an end date. Write it down before you write a single line of code. Then show up when the clock runs out and tell the truth about what you found.

That's the work.