The long conversation
A brief and a long conversation. We ask what the product is for, who uses it, what has to work on day one, and which parts are genuinely optional.
The approach
A build process you can actually sit inside
Most development processes are written to reassure, not to be used. This one is the working version — the shape we run on every app and game project, and the one we adapt when a brief does not fit.
Read it as a map, not a contract. The chapter structure stays consistent; the pace changes with the project, the platforms, and how fast decisions come back.
Week one
Scoping before code
No code is written until the scope exists in writing. That is the rule, and it holds on every project.
Then we cut
Most first drafts of a scope shrink by half once a client has to say out loud what they actually need. That cut is where the product gets sharp.
Platform and engine
A recommendation on which platforms to build for and which engine carries the build, argued from the product — not from what we most like to use.
The document you keep
A written scope, a milestone plan, and a rough cost range. You own that document whether or not you build with us. If you take it elsewhere, fine.
Milestones
Blocks that end in something you can install
After scoping, work runs in blocks. Two to four weeks is the usual length; the number depends on the project and the pace decisions come back at.
- iOS app TestFlight build, installable on the reviewer's phone Every block
- Android app Internal APK on a signed release channel Every block
- PC game Steam playtest key for a small, invited cohort Every block
- Web backend A staging environment wired to the real services Every block
Feedback happens against a running thing, not a slide deck. That single choice does more to keep a project honest than any process document.
Milestones are priced separately. If the direction changes materially between blocks, you can stop or redirect without renegotiating a lump sum that no longer makes sense.
Engine decisions cost the most to reverse
Engine, platform, and architecture decisions cost the most to reverse, so we make them in week one, on the call, with you in the room.
For apps, the questions are usually about device features, offline behaviour, and how many platforms you plan to maintain. Native wins when the product leans on the hardware; cross-platform wins when two codebases would be upkeep you cannot afford. For games, Unity covers most mobile and mid-scope PC projects and has the deepest hiring pool later. Unreal earns its place when rendering or console-first production drives the work.
We tell you when the answer is not the one you expected. It has happened more than once where a client arrived set on engine A and left the call convinced engine B was right — because the release plan, the team they could hire, and the platform they wanted to ship on all pointed the other way.
Design and build, running together
Design is not a phase that finishes before engineering starts. In our process they run together, which means a screen can change after an engineer has told you a state is expensive to handle. For apps, that is flows, empty states, error handling, and the dull corners users get stuck in. For games, it is the loop, the feedback a player receives when they press something, and the menus that sit between them and play.
A design handed over as a static file and never revisited usually drifts from the build. We avoid that by keeping the file open while the build runs, and by writing the handover documentation as systems are built rather than in a panic at the end.
Testing and QA
Testing on three flagship phones is not testing
Every project has a device list agreed at the start, and we check builds against the oldest hardware on that list, on purpose.
For apps that means current and previous major OS versions, a small Android, a large Android, and whatever device you consider your actual user. For games it includes the target console firmware if that is where the build is going.
Accessibility checks sit in the same list: scalable text, colour options, remappable controls, subtitles. All of it gets tested in the same pass, not remembered at the end. QA is not a milestone at the end of a project — it runs alongside the build blocks so problems surface while the code is still warm.
Launch week
Launch week is its own thing: store submissions, review feedback, release notes, the odd bug that only shows up on a real device, and a support plan for the first days after people start using the product.
We stay on through that week as standard. It is not a retained engagement, it is part of the build. Whatever breaks in the first days gets triaged by someone who knows the codebase. Console launches add their own requirements, and their accessibility guidelines differ by platform — we read them at the start, not the week before submission, because submission delays cost more than they save.
Handover
Everything the client keeps
When a project finishes, the client keeps the repository, the store accounts, the signing keys, and the documentation.
Documentation is written during the build, not in a panic at the end. Handover documents produced in the final week are usually thin and often wrong. Ours describe what actually shipped, because they were written as the systems were built.
If you continue with a retained support arrangement, handover is partly theoretical because we stay on. If you take it in-house, the material is there.
After launch
Post-launch is where a product earns its keep
It is also where a lot of studios quietly disappear. For apps, iterations usually mean crash fixes, OS update compatibility, small feature drops, and responding to store review comments.
For games they mean balance changes, event content, bug triage, and the small quality-of-life fixes that players actually notice.
We keep the retained team small and stable. That means the person who fixes a bug next quarter is often the person who wrote the system. There is a real cost to that model, and it shows up in our pricing. We think it is worth it.
- Apps live-ops
- Crash fixes, OS update compatibility, small feature drops, store review replies.
- Games live-ops
- Balance changes, event content, bug triage, quality-of-life fixes players notice.
Variants
When the shape has to change, only the middle does
Processes are tools. We keep the shape — scope first, milestone reviews, real builds — and change the rest.
- Prototype sprint
- A prototype built in ten days to answer one question. Skips most of the standard flow and runs as a single block.
- Port engagement
- Bringing an existing product to another platform. Starts with an audit rather than a scope, so the cost is honest.
- Embedded engineer
- A single engineer inside your team for eight weeks. Starts with a team introduction rather than a milestone plan.
If you have read this page and it does not fit what you need, say so in the brief. We will tell you which part we would change, and why.
Start where it counts
Bring us the brief. We will tell you the honest shape of the build.
A scoping week gives you a written scope, a milestone plan, a platform and engine recommendation, and a rough cost range — yours to keep whether or not you build with us.