The playable spec sheet: what to send a network before you build

Every playable that gets rejected or reworked after delivery had a chance to fail earlier and cheaper, at the spec stage, before a single line of build code existed. Sending a network a proper spec sheet before production starts isn't paperwork. It's the cheapest QA pass a playable ever gets, because everything it catches would otherwise surface after the build ships and the deadline is close.

Size limits, stated as a range not a target

Networks publish maximum file sizes. Treating the maximum as the target guarantees trouble, though; a build that lands at 4.9MB against a 5MB cap has no room for the last-minute asset swap, the extra font weight, or the additional language string that always shows up in review. Ask for the actual enforced limit, not the marketing number, and build to roughly 80% of it as a working target, leaving headroom for changes that happen after the first internal QA pass rather than before it.

MRAID version and what it actually supports

Not every network implementation of MRAID supports the same feature set, and assuming parity across networks is one of the most common causes of a playable that works everywhere except the one place it is actually running. Confirm the MRAID version each network's SDK targets. Confirm whether it supports the specific APIs the build depends on, such as the expand and resize calls, or orientation locking, and whether gaps exist between the spec's stated support and the SDK's actual behaviour. A spec sheet that only lists "MRAID compliant" without a version number hasn't told a producer anything useful yet.

Orientation and what happens when a device ignores it

State the intended orientation clearly, and separately state what the build should do if the host app or OS ignores that request, because it will happen on some share of devices regardless of what the spec says. A playable that assumes portrait and gets rendered sideways without a fallback plan does not fail gracefully. It fails visibly, in front of the exact audience the campaign set out to reach.

The end card is not an afterthought

The end card is part of the spec, not a decoration bolted on after gameplay locks. It needs its own dimensions and its own load-time budget, separate from the interactive portion, plus explicit confirmation of whether the network's SDK injects its own store-redirect button over the top of a custom one; that happens more often than producers expect and can leave two competing calls to action stacked on the same screen.

Network quirks worth asking about by name

Every network has particular behaviours that never make it into the public documentation: how a specific SDK handles a muted autoplay video, whether closing the ad early triggers a different postback than completing it, how aggressively a specific integration caches assets between sessions. None of this belongs in a generic spec template. It belongs in a short list of direct questions sent to the network's technical contact before the build starts, because the answer to a specific "does your SDK do X" is worth more than a page of general documentation written before this particular quirk existed.

Send the spec sheet at kickoff. Get answers in writing, and treat any network that can't answer basic questions about its own MRAID support or size enforcement as a signal about how the rest of the delivery process will go.

Related archive reading

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

• Playable QA: five failures networks reject
• A Year-End Playable File Size Load Time Audit to Run