Playable ad direction for games, built as game design

A playable ad gets about three seconds of thumb before it is scrolled past, and it has to arrive as one self-contained HTML file under the 5 MB ceiling that Meta, AppLovin, Unity Ads and ironSource all enforce. Those two constraints decide nearly everything else: one mechanic, no tutorial text, no engine export. What actually decides the ad: The mechanic, not the art. The playable carries a single interaction and teaches it without a line of instruction. Drag to place, aim and release, swipe to sort, tap to merge. Which one is a game design decision made against your retention curve and your first-session flow, and I make it in writing with the options I rejected and why. Most briefs arrive with the order reversed, art first, and the mechanic chosen last from what the art allows. How it is built: Hand-written canvas or PixiJS, bundled with esbuild into a single file with assets inlined. No engine export: a Unity WebGL build passes 5 MB before it draws a frame. mraid.js is never bundled, the network injects its own and a second copy breaks the close button on a fair share of SDK versions in the wild. Meta wants FbPlayableAd.onCTAClick() rather than mraid.open(), so each network gets its own build from one source, and you receive the source. Sprites are atlased, audio ships muted with a working unmute, and it holds 60 fps on a 2020 handset, which is what your Indonesian and Brazilian traffic is actually holding. QA happens on hardware, not in a simulator. What I refuse: Fake gameplay. The pin puzzle for a game with no pins, the deliberately unwinnable level, the fake progress bar. It lifts install rate and destroys D1 and D7, so blended CPA is worse three weeks later when nobody connects the two numbers. It is also irreführende Werbung under the UWG and a policy exposure in both stores. If the growth plan needs the ad to misrepresent the game, the brief will be cheaper elsewhere and I would rather say so now. I also do not do variant farming. Twelve builds a week is not testing, it is a way of avoiding the decision, and the reporting that comes out of it cannot be read by anyone. Not included: No media buying, no MMP or SDK integration, no ASO, no store listing assets, no game or app development, and no localisation beyond German and English. I brief and manage other languages; you pay the native reviewers directly. Who this is not for: Studios with no playable build of the real product, because I need something to play before I can tell you what to cut from it. Teams whose creative approval runs through six people, since the mechanic decision does not survive a committee. Anyone comparing quotes on cost per build. How it runs: Week one is play sessions on your build and the written mechanic recommendation. You can stop there and take that document elsewhere; two clients have, and it was the right call for both. If we continue, greybox in week two so the interaction is judged before any art exists, then art pass, network builds, device QA, handover. What comes back: A playable per network in its required wrapper, an end card matched to your store listing, the repository with a build script, and a short note on what the winning mechanic implies for the first session of the game itself. That last part is usually the more valuable half. A playable that converts is a tutorial that works, and the reverse is also true: if the mechanic cannot be taught in three seconds in an ad, it is worth asking how new players are meant to learn it in the game.