Most prototypes fail for a boring reason: nobody agreed what they were for. A build gets made, people play it, opinions are exchanged, and the decision to continue is made on enthusiasm. Six months later the numbers arrive and the enthusiasm is gone.
We run prototypes on a fixed pipeline of roughly four to five weeks, and the first week does not involve Unity. This is the schedule, the reasoning behind it, and what the framework we build on contributes at each step.
Week 0: The question
Before anything is built we write a one-page brief with four sections:
- Hypothesis. "A one-tap conveyor sorter will retain casual puzzle players at least as well as our board-sort titles."
- Audience and references. Who this is for and which live games they play today.
- The metric and the threshold. What we will measure (usually D1, D3, session length and an early CPI signal) and the number below which we stop.
- The creative angle. How this game will look in a three-second vertical video. If we cannot describe it, the concept is not ready.
This page is the contract for the prototype. It stops scope creep, and it makes the go / kill meeting a comparison against a pre-agreed number instead of a debate.
Week 1: Framework setup and the core interaction
Because every title starts on our CMZ Puzzle Framework, week one is not spent on menus, save systems or analytics plumbing. Those exist. The engineering time goes to the core interaction: the one input the player repeats a thousand times. For a sort game it is moving a cup; for a block game it is the slide; for a pairing game it is the tap-tap-match.
By the end of the week the interaction should feel good on a device — not in the editor — with placeholder art. If it does not feel good with placeholder art, better art will not save it.
In parallel, design produces the first 20–30 levels with the solver tooling, so difficulty is shaped from the start rather than guessed later.
Week 2: A complete loop
Week two turns the interaction into a loop: level select, win and fail states, the first booster, basic progression and the framework's default meta features switched on through configuration. Tracking is already live because the framework emits level, economy and session events automatically.
This is also when we produce the first capture build — a version with debug controls that lets the creative team record clean gameplay footage. Creative testing can begin before the game is pretty, and early CPI signals are worth more than a polished trailer.
Week 3: Making it a game
With the loop working, week three is about the things players remember: the theme, the feel of a clear, the first new mechanic, the onboarding. Art replaces placeholders for the core objects. Sound and haptics go in. The first 60–80 levels are tuned.
Design checks the chapter shape against the plan: where the first peak falls, when the first new element arrives, how a first session ends. Producers review the event taxonomy to make sure every question in the brief can be answered from the data we will get.
Week 4: Test build and readout
The build goes to a test market on Google Play through internal or open testing tracks, and UA runs small creative tests. From this point the pipeline is a measurement exercise:
- Cohort retention (D1, D3, and D7 if the window allows).
- Session count and length by day.
- Per-level funnels for the first two chapters.
- Creative CPI and click-to-install.
We give the readout two weeks of data where possible, which is why the calendar sometimes stretches to five weeks. At the end there is a one-page result against the one-page brief.
The go / kill meeting
The meeting has three possible outcomes, decided in advance:
- Go. Numbers clear the thresholds; the title moves to production with a defined scope for soft launch.
- Iterate. One or two metrics are close and the data points to a specific cause (a level, an onboarding step, a creative). One more sprint, one more readout, then a final decision.
- Kill. Below threshold without a clear fix. The mechanic goes into the framework's library — its code, levels and learnings are not wasted; most of our 25+ prototypes live there — and the team moves to the next brief.
The discipline is in the third outcome. Killing a prototype that the team likes is hard; killing one that missed a number everyone agreed on beforehand is merely sad.
What the framework contributes
It is worth being explicit about why the schedule is four to five weeks rather than three months:
- Progression, rewards, events, streaks, leaderboards are configuration, not features to build.
- Ads and IAP placements exist and report from the first build.
- Analytics — event taxonomy, cohort dashboards, level funnels — are inherited.
- Level tooling with solvers and validation is shared.
- Build pipeline for iOS and Android is ready.
The prototype team spends its weeks on the mechanic, the levels and the feel. That is the whole point.
Applying this with a publisher
When we prototype for or with a publisher, the brief is written together and the thresholds come from the publisher's portfolio benchmarks. Capture builds go to the publisher's creative team early, and the readout is a shared document. That structure has been the most reliable way we know to keep a prototype engagement honest for both sides.
We prototype new puzzle concepts on this pipeline for our own portfolio and for partners. Start a conversation.
