The 7-Day Prototype: How a Two-Person Team Ships a Testable Build Weekly

A seven-day prototype works because the scope is fixed before the week starts and the question is decided on day one. Two people can hold this cadence: one on mechanics and systems, one on content and feel. The output is a testable build and one clear answer, not a small game.

Why this matters

Teams that test ten concepts a quarter learn ten times as much as teams that test one. In a market where most concepts fail, the number of attempts is the strategy.

The barrier is almost never talent. It is that each prototype quietly grows until it is a project, and the cadence collapses.

A fixed week is what prevents that. The constraint is the method.

What a prototype is for, and what it is not

A prototype exists to answer one question with the least work that can answer it.

It is not a small version of the game. It is not a demo. It is not the foundation of the final build, and treating it as one is the most common way a week becomes a month.

If you would be unhappy to delete it on Friday, it is not a prototype any more.

Decide the question before anything else. Write it down in a sentence: does this mechanic hold attention for a minute, does this control scheme read on a phone, does this hook work in a three-second video.

A week aimed at one question finishes. A week aimed at "see if this is fun" does not.

Day 1: mechanic and grey box

The whole first day goes to the core interaction, with no art.

• Build input handling and the primary action first.
• Get one object responding correctly before adding a second.
• Hard-code everything. Values live in the script, not in a data file.
• End the day with something playable on a device, even if it is ugly and short.

The device build on day one is not optional. Input feel is different on a phone, and discovering that on day five costs the week.

Days 2 to 3: the loop is playable

These two days turn an interaction into a loop.

Add the win condition, the lose condition, and the restart. Then play it twenty times in a row yourself.

By the end of day three you should be able to hand the phone to someone with no explanation and watch them play a full cycle. If you have to explain it, the concept has a problem that art will not fix.

Keep the content minimal. Three levels or three minutes of play is enough to answer most questions, and building twenty levels this early is work you will throw away.

Day 4: feel pass

One day, and it changes the result more than any other single day.

Work in this order and stop when it reads well: animation on the primary action, sound for the action and the outcome, hit stop, a small screen shake, and a win sequence.

The win sequence matters most. It is the moment testers remember and the moment your creative will be cut from. The full approach is in Why Juice Sells.

Resist adding mechanics on day four. Feel days attract feature ideas, and that is how the week breaks.

Day 5: progression stub

Not a progression system. A stub.

Add the smallest thing that makes the second play different from the first: a level counter, a difficulty step, a score to beat. Enough that a tester has a reason to try again.

This is also the day to add the analytics events you will actually read. Session start, level start, level complete, level fail. Four events answer most prototype questions, and more than that becomes noise you will not have time to analyse.

Day 6: build, analytics, capture

Day six is production, and it is where teams that skip it lose the week's value.

1. Make a release build, not a development build, and test it cold on a real device.
2. Verify the analytics events actually arrive in the dashboard from that build.
3. Play a full session and record the screen.
4. Capture the best three seconds and the best ten seconds separately.
5. Take screenshots that show the mechanic rather than a menu.

Something always breaks between the editor and a release build. Finding it on day six is routine; finding it on day seven is a crisis.

Day 7: creative and submit

The last day exists because an untested prototype teaches you nothing.

Cut two or three short creatives from the footage. Show the mechanic without narration and check that it reads silently.

Then send it: to a publisher, to a creative test, or to a group of players. Which one depends on your question, and the packaging checklist is in The Publisher Submission Checklist.

Write the week's finding in three sentences before you close the laptop. What was the question, what happened, what would you do next. That note is the asset that survives.

The rules that keep it to seven days

Six rules, and the cadence holds or fails on them.

• The question is written down on Monday and does not change.
• No new mechanics after day three. Ideas go in a list for next week.
• No art beyond flat colour and one font. Art is the largest hidden time sink at this stage.
• No accounts, no cloud save, no settings menu, ever.
• A device build exists every day from day one.
• Friday is a hard stop. An unfinished prototype is deleted or scheduled properly as a project, not extended by "just two more days".

That last rule is what actually protects the cadence, and it is the one teams break first.

What we would do

Run the week the same way every time, so the process stops needing decisions. Same days, same outputs, same Friday note.

Keep an idea list running between weeks so Monday starts with a candidate rather than a brainstorm. Ideation is a separate activity with its own rhythm, covered in Ideation Systems.

Accept that most weeks will produce a no. That is the process working. The value is in how cheaply you reached it, and how many more you can run this quarter.

The short version

• Write the question down before the week starts, and do not change it.
• Day one is mechanic and a device build. Days two and three make it a loop.
• Day four is feel, and the win sequence matters most.
• Day five adds a progression stub and four analytics events.
• Day six is a release build, verified events, and captured footage.
• Day seven is creative and submission, plus a three-sentence finding.

Pick one question and run a single week end to end before changing anything about your process. If you want a team that can run these alongside yours, get in touch.

Related reading: Stop Polishing, We Rebuilt a Top-Grossing Puzzle Loop in 48 Hours, and Ideation Systems.