The Handoff Problem in Multi-Network Playable Production

Our 2025 guide, From Playable Prototype to Five Network Builds, No Rework, argued that most rework comes from skipping the specification check before anyone writes the brief, and built a worked example around reading network limits before the first asset exists. A year on, that discipline is table stakes at most studios that shipped it more than once, and the rework that survives now shows up later in the process.

A prototype that plays well on a laptop still isn't a deliverable. It's the easy 70%. The remaining work, forking one build into five network-ready packages, is where playable teams now lose days, not to unread specification sheets but to markup layers tangled with game logic and handoffs with no named owner.

Constraint discipline: still the starting point

Every network has a file-size ceiling, and they're not the same number. Build your prototype against the tightest limit in your target list from day one, not the most generous one; compress audio and texture-atlas early, and strip debug tooling before you fork rather than after. Retrofitting a build designed against a 5MB ceiling down to fit a 2MB one usually means re-authoring assets, not just re-exporting them. Orientation and aspect ratio follow the same rule. Decide up front which builds need portrait, which need the wider horizontal orientation and which need both, and at what aspect ratios the UI has to hold together, because retrofitting layout across five branches later costs a day of patches that a twenty-minute matrix, drawn network by network, would have avoided.

Separate the markup layer from the game logic

MRAID and custom SDK requirements differ by network: some want a single self-contained HTML file, others expect specific click-through macros or a particular end-card structure. If your click-tracking code lives inside the same files as your game logic, alongside the end-card and the orientation lock, every network variant becomes a manual edit with its own chance of a regression. Keep those pieces in a thin adapter layer that you swap per network. The core game stays untouched across all five builds. Once you have five adapters sitting on top of one core, treat each as its own small codebase with its own version history, so that when a network changes a requirement you can see exactly what changed in that one adapter without touching the other four.

QA the base build before you fork, not after

Every bug in the base build gets multiplied by five once you branch. Run a full QA pass, device coverage included, on the base build before creating a single network variant; fixing a physics bug once in the trunk is fast, and fixing the same bug five times after divergence, with five sets of network-specific edge cases layered on top, is not. The same logic applies to network specs themselves. Keep a living reference of what each network actually requires today (size limits, supported ad formats, click-macro syntax, review turnaround) and update it after every rejection rather than waiting for the following build cycle. A team that treats network requirements as one producer's tribal knowledge pays the same rework tax whenever that producer is off during a delivery week.

The handoff problem in multi-network production needs an owner

Rework often has less to do with technical structure than with who is responsible for catching a network's rejection email and translating it into a fix. If the answer is "whoever sees it first", fixes queue up behind other work and network reviewers see the same broken build twice. Assign one person per delivery cycle to own the network relationship end to end, from submitting the build through reading the rejection notes to routing the fix back to the right adapter file. That person doesn't need to write code. They do need to know which network quirk lives where, and they need the authority to hold a build back rather than ship something they know will bounce.

The build that ships to five networks without rework isn't the one built fastest. It's the one where every decision that varies by network got identified and isolated before anyone duplicated a single asset.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• From Playable Prototype to Five Network Builds, No Rework
• A Creative Brief Template That Playable Teams Actually Use