When to Kill a Game and What to Salvage

Decide the kill criteria before starting, write them down, and check them on a schedule. Without that, the decision gets made by exhaustion or by running out of money, both of which destroy more value than an early stop. Most of what a cancelled project produced is worth keeping.

Why this matters

Almost every game a studio starts will not be the one that works. That is normal in this market and it is priced into how studios operate.

What separates studios is not how often they stop, it is how well. A project stopped cleanly at the right moment returns team capacity, learning, and reusable work. One stopped after nine months of hoping returns none of those.

The decision is much easier when the criteria were set while everyone was still optimistic.

Setting kill criteria before you start

Write these at the beginning of the project, alongside the scope.

Each criterion needs three parts: what is measured, the threshold, and the date it is checked.

• A test result by a date. "If the prototype does not hold attention for two minutes by week three, we stop."
• A cost threshold. "If we pass a stated spend without reaching the first milestone, we review."
• An external signal. "If no publisher engages after three submissions, we reassess."
• A team signal. "If nobody on the team wants to play it after a month, that is a finding."

The point is not that these are automatic. It is that they force a scheduled, explicit conversation rather than an ambient sense that things are not going well.

A kill criterion written on a good day is worth ten hours of argument on a bad one.

The signals that mean stop

Some patterns are reliable across projects.

1. The loop does not hold attention with real players, after several genuine attempts to fix it.
2. Every test result is flat. Not bad, flat. Games that will work usually show a signal somewhere.
3. The fix list keeps changing. Each round produces a new theory, which means nobody knows the actual problem.
4. The team stops playing it voluntarily. A quiet, honest signal that arrives early.
5. The cost to reach a decision keeps rising. When each new answer costs more than the last, the project is consuming rather than producing information.
6. The market moved. The assumption the game was built on is no longer true.

Two or three of these together is a strong case. One alone usually is not.

Signals that do not mean stop

Worth naming, because they cause premature cancellations.

• A bad week. Short-term variance is not signal.
• A competitor launching something similar. Frequently a validation of the space rather than a reason to leave it.
• Loud negative feedback from a small group. Check whether it is representative before acting.
• Boredom. Teams get bored of every project around the midpoint. That is fatigue, not evidence.

Separate these from the real signals deliberately, because they feel identical in the moment.

Sunk cost, named plainly

The money and time already spent are gone whatever you decide. They should carry no weight in the decision.

That is easy to state and hard to practise, so make it procedural.

Ask the question in a neutral form: if this project arrived on your desk today, in exactly its current state, with the remaining budget and the current results, would you start it?

If the answer is no, the only thing keeping it alive is what has already been spent.

Two habits help. Have the conversation with someone who was not involved, and write the answer down before discussing it as a group, so the first person to speak does not anchor everybody else.

What is worth salvaging

A cancelled project is not a write-off. Four categories usually survive.

The one that most often gets lost is the learning, because nobody writes it down when a project ends badly.

Spend a day on a written post-mortem before the team disperses. What was the hypothesis, what did the tests say, what would you do differently, what would you keep. That document is the actual return on the project.

The reuse boundary is the same one in The Second Game Problem: infrastructure carries forward, design should be re-examined.

Telling your team and your investors

The team. Tell them directly, early, and in person where possible. Explain the criteria and how they were applied, which turns an arbitrary decision into a legible one. Then say what happens next, because the uncertainty is worse than the news.

Give credit for the work. A cancelled project is not failed work, and treating it as such makes people cautious on the next one, which is the opposite of what you need.

Investors. Lead with the decision, then the reasoning, then the plan. Investors have seen this many times and generally respond well to a founder who stops decisively.

Three things to include: what you learned, what you are carrying forward, and what the runway looks like now. The framing that works in these conversations is in What Your Board Will Ask at Month Six.

Starting the next one faster because of it

The value of stopping well shows up in the next project.

• Reuse the infrastructure immediately, while it is fresh and somebody remembers how it works.
• Read the post-mortem before writing the next plan, which is the only way it earns its cost.
• Change one thing about the process, not five. A single deliberate change per project compounds.
• Give the team a short break before the next search. Starting straight into a new concept after a cancellation produces poor judgement.

Studios that do this consistently develop something valuable: an accurate sense of how long it takes them to know whether an idea works.

What we would do

Write kill criteria into the project plan, with dates, at the same time as the scope. It takes twenty minutes and it is the difference between deciding and drifting.

Review them on the scheduled dates whether or not anyone is worried. A scheduled review is easy; an unscheduled one feels like an accusation.

When the answer is stop, stop quickly and spend the last day writing the post-mortem. Then take the tooling, the assets, and the document into the next project deliberately rather than by accident.

The short version

• Write kill criteria with thresholds and dates before starting.
• Real signals: a loop that will not hold, flat results, a shifting fix list, and rising cost per answer.
• A bad week, a competitor, and team boredom are not signals.
• Ask whether you would start this project today in its current state.
• Salvage tooling, assets, and above all the written learning.
• Tell the team directly with the reasoning, and tell investors the decision first.

Add kill criteria to your current project plan today. If you want an outside read before making the call, tell us where things stand.

Related reading: Update, Pivot, or Shut Down Your Game, Rescuing a Stalled Game Project, and The Second Game Problem.