What to Cut When a Prototype Runs Past Seven Days

A prototype that passes the seven day mark has usually added work that does not serve the test. The purpose of a prototype is to answer one question about the core mechanic, and everything that is not answering that question is slowing you down. Cut to the test, ship it, and learn.

Why this matters

Speed is the single largest advantage a small team has in the publisher prototype cycle. A prototype that takes three weeks instead of one means three times fewer concepts tested per quarter.

The features that extend a prototype past seven days are rarely the ones publishers evaluate. They evaluate the feel of the core loop and the install cost of the creative. Everything else is noise at this stage.

Knowing what to cut is a skill, and it is more valuable than knowing what to build, per When to Kill a Game and What to Salvage.

Signs the prototype has grown past its purpose

Five signals that scope has crept in.

1. You are working on a second mechanic. The prototype only needs to test the primary one.
2. You are building progression. Levels, unlocks, and upgrade tracks belong in the next phase.
3. You are polishing art. Placeholder art is fine for a mechanic test. Polish comes after the numbers justify it.
4. You are adding a menu system. A prototype needs a play button and the game. Nothing else.
5. You have more than two scenes or screens. The test needs the loop and the loop alone.

Any of these individually can add two to four days. Together they can triple the timeline.

A prototype is not a small game. It is a question in playable form.

What to keep

Three things, and nothing else.

The core interaction. The one thing the player does repeatedly. Swipe, tap, drag, aim. This must feel right because it is the thing being tested.

One level of content. Enough to play the loop three or four times. This can be hand-built and does not need a generation system.

The creative hook. The visual or conceptual element that would appear in an ad. If the prototype cannot produce a five-second clip that looks interesting, the CPI test will fail regardless of the mechanic.

Everything else is a candidate for cutting.

What to cut

Be specific. These are the items that most commonly extend a prototype past a week.

The common thread is that each of these is a real requirement in a real game. None of them is a requirement in a prototype.

How to decide what stays

One question settles most scope debates at the prototype stage: does this change what the CPI test tells us?

If the answer is no, cut it. A menu screen does not affect install cost. A score system does not affect whether someone taps the ad. A tutorial does not appear in the creative.

If the answer is maybe, ask a second question: can it be added in a day if the test passes? If yes, cut it now and add it later. The cost of adding it after a passed test is low. The cost of building it before a failed test is total.

The seven day budget

A useful prototype budget for a solo developer or a small team.

• Day one. Core mechanic, playable but rough.
• Day two. Feel pass. Timing, feedback, the moment-to-moment experience.
• Day three. One level of content that demonstrates the loop clearly.
• Day four. Visual hook. The element that makes the creative clip interesting.
• Day five. Creative production. Record the video for the CPI test.
• Day six. Build, test on device, fix crashes.
• Day seven. Submit the test.

Notice that days five through seven are about testing, not building. The build should be functionally done by day four. If it is not, something from the first four days should have been cut.

What we would do

Set a hard seven day cap at the start and treat it as immovable. Scope can shrink to fit the time, but the time does not stretch to fit the scope.

Write the one-sentence test question before opening the engine. "Does this swipe mechanic produce a CPI under $0.30?" is a question. "Build a fun puzzle game" is not. The question determines what stays and what goes.

Then review the scope on day three. If the build is not playable by the end of day three, something needs to be cut immediately. Waiting until day five to make scope decisions is too late to recover the schedule.

The short version

• A prototype that runs past seven days is carrying scope it does not need.
• Keep only the core interaction, one level of content, and the creative hook.
• Cut tutorials, score systems, multiple levels, settings, sound, analytics, and save systems.
• Ask whether each feature changes what the CPI test tells you. If not, cut it.
• Budget days five through seven for testing, not building.
• Set the time cap first and shrink scope to fit it, never the reverse.

Check your current prototype scope against this list today. If you want a prototype scoped and built in seven days, tell us the concept.

Related reading: When to Kill a Game and What to Salvage, What Voodoo Actually Looks For, and How Publisher Submission Bars Differ.