From Playable Prototype to Five Network Builds, No Rework

The single most avoidable cost in playable production is discovering, after the creative director has approved the prototype, that it needs rebuilding five times because nobody checked the playable ad network specifications before development started. Every network that runs playables (Meta, Google, TikTok, Unity, Mintegral, the rest of them) sets its own file size cap, its own required end-card behaviour and its own quirks in how the WebView renders. A prototype that pleases a review meeting isn't the same artefact as five compliant network builds. The gap between the two is where most playable teams lose a week they didn't budget for.

Read playable ad network specifications before the first line of code

The fix isn't a better build pipeline. It's sequencing: pull every target network's current specification sheet before the prototype exists, not after. That means confirming file size ceilings, which still vary meaningfully across networks and can tighten without much notice, confirming whether the network requires an embedded end card or renders its own, and confirming which orientations and aspect ratios are mandatory versus optional. A prototype built against the tightest constraint in the set, usually the smallest file size cap, degrades gracefully everywhere else; a prototype built against the most generous constraint has to shrink five times instead of growing once.

Where playables actually break across networks

The failures that eat the most time cluster in a few predictable places:

• Asset weight. Video-based fallbacks, particle effects and high-resolution UI elements are the first things over budget when a build has to shrink to fit a stricter network's cap.
• Touch and gesture handling. A drag mechanic tuned for one network's WebView can register differently on another, especially where click-through areas are simulated for tracking rather than natively touch-driven.
• End-card and CTA logic. Some networks want the end card baked into the playable's own code; others expect the playable to hand off to a network-rendered end card and will reject a build that tries to do both.
• Load time on cold start. A playable that loads acceptably fast on a fast test connection can miss a network's load-time requirement on the throttled connections its review process actually tests against.
• Orientation locking. A build that assumes landscape-only will fail outright on a network whose ad unit expects the playable to respond to device rotation.

Each of these is fixable in isolation. The expensive version is fixing all five after the fact; by then a client or internal stakeholder has already signed off on a prototype nobody built with them in mind.

There's a sixth, less obvious failure mode: tracking and measurement integration. Every network expects its own click and impression tracking macros wired into the build in a specific way, and a playable that fires the wrong event, or fires the right event at the wrong point in the interaction, can pass functional review while quietly breaking attribution once it goes live. This one costs the most because the network's own QA process often misses it entirely. It surfaces weeks later as unexplained gaps between a network's reported clicks and an MMP's recorded installs, by which point tracing the fault back to a specific build decision takes far longer than checking the macro placement would have taken during initial QA.

A production checklist for multi-network playables

A practical sequence looks like this:

• Pull specification sheets for every target network before scoping the brief, and note the single tightest constraint in each category: file size, load time, supported orientations, end-card handling.
• Build the core mechanic against those tightest constraints from the first prototype, treating any network with more generous limits as a bonus rather than the baseline.
• Separate the mechanic layer from the network-integration layer in the codebase, so swapping tracking macros, click handlers or end-card logic for a different network does not touch the gameplay code at all.
• Run a device and connection matrix test, not just a desktop preview, before calling any build final. A playable that looks fine in a browser preview at full bandwidth can behave differently on the throttled, older devices a network's own QA process is likely to test against.
• Version each network build explicitly and keep a change log, because networks update their specifications during the year and a build accepted six months ago may not pass review today without changes.

A worked example

A hypothetical merge-mechanic playable built for five networks illustrates the gap. Built against a single generous 5MB assumption, the prototype passes review on two networks and fails on three, each for a different reason: one caps assets closer to 2MB, one requires a native end card the build had baked in instead, one flags an orientation lock the ad unit doesn't support. Rebuilding after rejection takes a production team roughly three to four working days per network. Call it two weeks of the two-week production cycle spent entirely on rework. Built instead against the tightest known constraint from day one, with the mechanic layer kept apart from the network-integration layer, the same playable typically clears all five reviews within one additional day of network-specific QA per build, because the differences left to fix are minor rather than structural.

The discipline pays off before the first optimisation cycle

Getting the specification work done up front saves more than a production cycle. It means the optimisation phase, where a team is normally testing hook variants and pacing changes against live performance data, starts a week earlier, on a build that's already running everywhere it needs to. It also changes the conversation with a client or internal stakeholder reviewing the prototype. The sign-off in that meeting becomes a sign-off on something that already survives five different sets of network rules, rather than on a single best-case version the team still has to renegotiate against reality afterwards.

The habit belongs in the brief template itself, not only in the production process. A brief that lists target networks alongside the mechanic concept forces the specification check to happen before anyone produces a single asset, rather than leaving it as a step someone has to remember later in the schedule. As we argued in The Playable Ad QA Checklist to Run Before Submission, most playable QA failures are specification failures wearing a QA costume. Same fix for both. Read the network's current rules before anyone writes the brief, not once the build is complete.

Related archive reading

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

• The Handoff Problem in Multi-Network Playable Production
• Playable tooling in 2026: build, buy or outsource