Studio
+44 20 7924 0137 [email protected]12 Clerkenwell Road, London EC1M 5PQ, United Kingdom
Monday to Friday, 9:00 AM – 6:00 PM
STUDIO NOTES
These are working notes. Practical things we have learned from shipping apps and games, written for people making decisions about their own products. They are the kind of conversation you would have with us on a first call, written down so you can read them before that call.
Most of them are about trade-offs, because that is what product decisions usually are. There is rarely a right answer that fits every project. Each note below stands on its own, and if one of them matches a decision you are holding right now, that is the one worth bringing to the call.
PLATFORM PLANNING
The framework question gets asked more than any other, and the honest version of it is rarely "which is best" — it is "which one fits the product you are trying to build and the team you will need in year three".
A quick way to know which path you are on: if the product would fail without one deep hardware feature, native is not a preference, it is a requirement.
Question 1
Does the product lean on the device?
Camera, background processing, offline storage, sensors, measurable frame performance.
Question 2
How many platforms must ship?
Two maintained codebases are a real recurring cost, not a one-off engineering decision.
Question 3
What can you spend on upkeep?
Plan the next three years of maintenance, not just the first release date.
THE COMPARISON
Native
Wins when the app needs deep access to camera, background processing or offline storage, or when performance is measurable and the product's character depends on it. Two native codebases are expensive, and staying current across a platform release cycle is the ongoing bill.
Cross-platform
Wins when the product is mostly screens and API calls. Flutter and React Native are both serious, current choices in 2026, and both have real limitations — if your product depends on a feature neither framework handles well, that decides the question.
Hybrid
Fits content-heavy products that do not lean on device hardware. In most of the projects we have seen, it also ages worse than either of the other two — the web layer eventually becomes a puzzle you keep solving.
ENGINE CHOICE
Both engines ship good games. The choice is usually about scale, team, and what comes after the build — which is often a hiring question more than an engineering one.
MOBILE · MID-SCOPE PC
The default for most mobile and mid-scope PC work. The asset pipeline is comfortable for smaller studios, and its hiring pool is the deepest if you plan to grow the team a year or two from now.
HIGH-FIDELITY · CONSOLE
Earns its weight when rendering, large environments, or console-first production are the point. The ramp for a new engineer is longer, and that ramp is worth planning for.
ONE THING WE WILL SAY OUT LOUD
We work in Unity and Unreal. Godot is growing in the indie space, and the hiring pool is smaller, which matters if you plan to expand. If your project would genuinely be better in Godot, we will say so and point you somewhere else.
ACCESSIBILITY
Accessibility is usually treated as a checklist at the end. It is cheaper and better to fold it in from the start, and the specific items are not mysterious.
ON THE DESIGN SIDE
ON THE TECHNICAL SIDE
Submission delays cost more than the work itself, and consoles differ from each other. Accessibility done well is invisible to most players and the difference between finishing a product and abandoning it for users who need it.
APP STORE LAUNCH
Store review is not random. Most rejections come down to a small set of issues that are easy to avoid, and the ones we see repeat across clients week after week.
OUR RECENT REJECTIONS, IN ORDER OF HOW OFTEN THEY APPEAR
01
Missing privacy declaration fields
The forms in App Store Connect and Play Console ask for specific data types and uses; the forms still get submitted with fields left blank, which is a straight rejection.
02
Unclear purpose strings for permissions
The line of copy that appears when the app asks for the camera or location has to explain, in plain language, what the app does with it.
03
Account deletion paths that do not work
Both stores now expect a working deletion flow from inside the app, not a support email that replies in three days.
04
Subscription terms not visible before purchase
Price, renewal window and cancellation terms have to be on the screen the user sees before they tap subscribe; burying them in a link surprises clients and reviewers alike.
05
Wrong age rating or hidden in-app purchases
For games this trips up more first-time submissions than anything else. Apple and Google both want the user to know what they are getting into before they tap.
The safest approach is a pre-submission pass against the current guidelines a week before you submit, not a day before. Those guidelines change, and the changes are usually documented.
PROJECT TIMELINES
Clients ask how long an MVP takes or how long a mid-scope PC game takes. The honest answer is that it depends on scope and on how quickly decisions come back — and the second one is louder than most teams expect.
A focused mobile MVP usually runs a few months from signed scope. That assumes scope is stable and decisions come back in days, not weeks. A small game prototype or vertical slice can land in a similar window from the same starting point.
Anything with accounts, payments, or live services adds time on top of the build itself. Anything with a publisher adds a milestone structure to fit into, which usually smooths scheduling but also adds review cycles and their own scheduling.
What we will not do is give a date before the scope exists. Dates given at that stage are guesses, and they set up a bad conversation six weeks in.
PLATFORM MOVES
Porting looks simple from the outside and is not. A project that runs cleanly on one platform can hit a wall of small differences on the next — and the wall is usually built from small things, not one big one.
We start porting work with an audit, not a scope. What runs, what does not, which libraries need replacing, which design decisions were made against the platform you are moving to. Then the work gets quoted in blocks, so you can see what each piece of the port is actually paying for.
WHAT THE AUDIT USUALLY SURFACES
Cheap porting often means the port behaves like the original on a bad day. Clients who care about platform fit should expect to pay for the audit and for the fixes the audit surfaces.
PROTOTYPE · PITCH
A prototype is not a smaller version of the final product, and treating it that way wastes time on the wrong things.
THE PROTOTYPE
Does the core loop hold, does the art direction land, does a specific system work as designed. One question, answered properly, is worth more than four unanswered ones.
THE PITCH BUILD
Publishers and investors want to know what the game feels like when someone is actually playing it. A rough build with a clear mechanic says more than a polished trailer that hides the loop.
THE MEETING
The studios that pitch well tend to be the ones who can put a playable slice in someone's hands in the same meeting. That is the format to build toward, not the trailer.
Six weeks is usually enough to answer one question well. Twelve weeks to answer four badly is not. When the answer is clear and the build needs to go somewhere, we help decide whether the next step is a pitch, a vertical slice, or another pass at the prototype.
See work we have shipped
Painted environment from a published world-building project — a ridge line at dusk, one fire lit in a doorway.
PUBLISHER OR NOT
A publisher brings money, marketing, and distribution, and takes a share of the upside in return. A direct release keeps ownership and margin and takes on the entire risk. Neither is better — it depends on the project, the team, and how much capital is on the table.
The UK has both models well represented: Team17 sits on the publisher side and has built a long business across both roles. For a project that needs a budget it cannot self-fund, a publisher arrangement is the realistic path. For a project with a smaller scope and a clear audience, direct release is often the better economic outcome.
What matters is knowing which one you are choosing and why, not drifting into one by default.
DESIGN SYSTEMS
A design system built for a launch is often wrong for a product two years later. The parts that survive are usually the ones that were smallest and most flexible to start with.
We tend to build design systems around a small set of tokens and components, and let the specific patterns emerge from real screens rather than a hypothetical style guide. When a product grows, the tokens hold and the specific components get replaced.
WHAT SURVIVES
WHAT DOESN'T
If you are building for the long term, small and flexible beats comprehensive and rigid. It is not the answer most teams want.
IF ONE OF THESE IS YOUR QUESTION
These notes are the kind of conversation we would have with you on a first call. If a decision in here matches the one you are holding, a 30-minute call is usually enough to give you a direction — and if not, a short brief by email is the next easiest step.
