PRODUCT DECISIONS BEFORE DEVELOPMENT
Define the game before the team starts building it.
Product design for one agreed game, major feature, or defined set of systems that needs a clear loop, scope, screen behaviour, economy, and technical rules.
WHEN IT FITS
Use this when the next decision needs to be clearer.
- The concept is promising, but the player journey and release scope are still moving.
- Design, product, and development need one agreed version of how the game should work.
- A template or early prototype needs a product decision before more engineering time is spent.
WHAT WE AUDIT OR DESIGN
The work stays tied to the decision.
- The core loop, player actions, game states, screen flow, rewards, economy, and release scope.
- Technical rules that affect product behaviour, including wallet state, settlement, recovery, errors, and browser or mobile constraints.
- Features that belong in the first release and features that should wait.
WHAT YOU RECEIVE
Your team gets clear instructions.
- A complete player journey and game-state map.
- Rules for screens, actions, rewards, economy, and important edge cases.
- A controlled first-release scope that shows which features should wait.
- A product specification that development and QA can work from.
What we need from you
The concept, existing template or prototype, business constraints, platform, intended audience, and any technical or compliance requirements already known.
How the work is measured
Before development, we define the behaviours and product questions that need telemetry. After release, the team can validate the core loop, feature use, failure states, and return-to-play behaviour against the agreed product goals.
RELEVANT WORK
See what this looks like on a real game.
QUESTIONS BEFORE STARTING
What teams usually ask.
Do you design the whole game or one feature?
Both are possible. Before the work starts, we agree on the game, major feature, or set of systems included in the project.
What if the game has a much larger scope?
Larger games and multi-system products are quoted separately. They can also be split into clearly defined phases.
Do you provide visual UI files?
The exact visual output depends on the scope. The core deliverable is the product behaviour: what each screen and state must do, how the loop works, and what the team needs to build.
Do you develop the game?
No. We define the product and write each decision in enough detail for your development team to build and test it.