When to Kill a Prototype Before the Test

Not every prototype deserves a market test. Testing costs money and time, and spending both on a prototype that already shows problems in the studio is waste. There are five signals that a prototype should be killed before reaching a test audience, and learning to read them saves more budget than any improvement to your testing process.

Why this matters

The default instinct is to test everything. The reasoning is sound: data is better than opinion, and a market test produces data.

But a market test also costs install budget, creative production time, and a week of waiting. If the prototype has structural problems that no amount of player data will fix, that spend is better allocated to the next concept.

The skill is distinguishing between "I am not sure this works" and "I can see this does not work." The first deserves a test. The second does not.

Signal one: the mechanic does not feel right in your hands

Play the prototype yourself for five minutes. Not testing it. Playing it. Put down the checklist and play.

If the mechanic does not feel satisfying to you, the person who designed it, it will not feel satisfying to a stranger who has no context and no investment.

This is not about whether the mechanic is fun in theory. It is about whether the act of performing it, right now, in this build, produces something enjoyable.

A prototype with good feel and unclear direction is worth testing. A prototype with clear direction and bad feel is not.

If you do not enjoy playing it after building it, spending money to confirm that strangers agree is not a good use of the budget.

Signal two: nobody can explain what they are doing

Show the prototype to three people who have never seen it. Do not explain anything. Watch.

If all three struggle with the same moment, the problem is in the prototype. If they struggle with different moments, the problem may be solvable. If they can play it without help but do not choose to continue, the mechanic has a replay problem, not a clarity problem.

The specific version of this test matters. Do not ask "do you like it" or "is it fun." Ask "what are you doing right now" thirty seconds in. If they cannot answer, the prototype is not clear enough to test.

Clarity problems are sometimes fixable in a day. But if the mechanic is fundamentally hard to parse visually, no amount of polish will fix what a redesign needs to address.

Signal three: you cannot describe the game in one sentence

A prototype that cannot be pitched in one sentence is usually too complicated to test.

The sentence is not for marketing. It is a diagnostic. If you cannot describe the core action simply, the core action is probably not simple, and a player will face the same confusion in the first three seconds.

Try this format: "You [verb] the [thing] to [goal]." If the verb, thing, or goal requires a qualifier, the mechanic has too many moving parts for a prototype.

Good examples:

• "You stack blocks to reach the top."
• "You dodge obstacles by swiping left and right."
• "You match colours to clear the board."

If your sentence starts with "So first you..." or includes the word "then," the scope exceeds what a prototype should carry.

Signal four: the replay has no variation

Play the prototype ten times in a row. If the tenth time feels identical to the first, the mechanic has no variation, and a market test will show strong first-session numbers followed by zero returns.

Variation can come from randomness, from skill expression, or from context changes. But it must come from somewhere. A mechanic that produces the same experience every time is a toy demonstration, not a game prototype.

This is checkable without a test audience. If you are bored on repetition five, the data will confirm what you already know, and it will cost money to do so.

Signal five: the problem is structural, not surface

The most important signal and the hardest to accept.

Surface problems are fixable: the art is placeholder, the sound is missing, the UI is rough, the opening is too slow. These are reasons to improve the prototype, not to kill it.

Structural problems are not fixable within the prototype's concept. Three examples:

• The mechanic requires a tutorial. If the core action cannot be understood without explanation, the mechanic is too complex for the context it was designed for.
• The fun only starts after thirty seconds. Mobile players decide in the first five. A delayed payoff is a structural problem when the platform does not support the delay.
• The mechanic conflicts with the platform. A precision mechanic on a touchscreen with large fingers. A slow mechanic in a context where players have ten seconds. These are not polish problems.

If the problem is structural, kill the prototype and start the next one. The concept may be valid on a different platform or with a different audience, but testing it here will only confirm the mismatch.

How to make the decision

A checklist to run before committing test budget.

1. Does the mechanic feel satisfying in your hands?
2. Can three people play it without help?
3. Can you describe it in one sentence?
4. Does the tenth play feel different from the first?
5. Are the remaining problems surface, not structural?

If all five pass, test it. If one fails, consider whether it is fixable in a day. If two or more fail, kill the prototype and move on.

Moving on is not failure. It is the pipeline working correctly. A killed prototype that saves a week of testing budget is a net positive for the next concept.

What we would do

Run the five checks above before every market test. Make the kill decision on Thursday, before spending Friday on test setup.

Keep a log of killed prototypes and why they were killed. After ten cycles, the log shows which problems recur, and that pattern is worth more than any single test result.

Then protect the team's morale. A killed prototype is a decision, not a defeat. The pipeline exists to produce kills as often as it produces tests.

The short version

• Not every prototype deserves a market test.
• Kill it if the mechanic does not feel right, nobody can play without help, or you cannot describe it in one sentence.
• Kill it if the tenth play is identical to the first or the problem is structural.
• Run five checks before committing test budget.
• A killed prototype that saves a week of testing spend is a win, not a loss.
• Keep a log of kills and look for patterns after ten cycles.

Run the five checks on your current prototype before your next test spend. If you want a second opinion on whether a prototype is worth testing, send us the build.