Rich Media and Playable Units Built to the Ingest Spec

Every unit is built against the receiving specification before a frame of it is designed. In-app display goes to MRAID 3.0, video to VAST 4.2 with OM SDK measurement, and standard display holds the IAB initial load budget of 150 KB with the rest polite-loaded once the page settles. Playables ship as one self-contained HTML file inside the five megabyte zip most networks enforce. Creative that ignores the spec is rejected at ingest, and a rejected unit is not creative. Where these run: In-app inventory through the exchanges you already buy, playables on Meta, Unity, AppLovin and ironSource, expandable and interactive display through your existing ad server, and video units where the interaction has to survive being served as VAST into an environment nobody controls. The build: Hand-written HTML, CSS and JavaScript by default, or Google Web Designer, Studio or Celtra when you already pay for one of them. We will not make you buy tooling to work with us, and we will not dress our preferred stack up as a strategic decision. Interaction is designed against your measurement stack rather than against a showreel. The event map is agreed before layout: expansions, dwell, video quartiles through VAST, custom interactions through OM SDK, and the post-click handoff into your MMP with the deep link tested on a real handset. If a proposed interaction cannot be counted in the tools you actually have, we do not build it. An uncounted interaction is a story you end up telling for the rest of the flight without evidence. Dynamic units are built on feeds that exist. We will wire a listing, inventory or job feed into a unit and design its failure states properly, including what it shows when the feed is empty or stale, which is the case everyone forgets and everyone eventually ships. We will not build a personalisation layer over data you do not hold. Quality assurance: A device matrix covering iOS Safari and WKWebView, Chrome on Android and the Android WebView, the network's own playable validator, and a preview inside each exchange that will carry the unit. We test on a throttled connection, not only on office wifi. You get the QA record itself, not an assurance that QA happened. What we refuse: VPAID, deprecated and blocked across most in-app inventory. Auto-playing audio. Any unit that imitates a system dialogue, a fake close control, or a button that does not do what it appears to do; those get pulled by store review teams, and they are the reason interactive advertising has the reputation it has. Interstitials without an honest exit. Not included: Media planning and buying, tag trafficking beyond one QA round alongside your ad ops team, the landing page and post-click experience, and campaign concepting when we are not directing the campaign. Versioning of a unit built by somebody else is quoted case by case and is usually declined. Who this is not for: A single flight with no follow-up. These units pay back when the first one is read against its event data and the second is rebuilt from what it showed. One burst teaches nobody anything, and if that is the plan, plain display will spend the budget more honestly. How we work: A creative director and a build engineer, both on the account from kickoff, sitting in the same channel as your ad ops and analytics people from day one rather than arriving at handover. Specification questions get answered in hours, which is the only reason work like this lands on a date. When the exchange changes a rule mid-flight, and one of them will, you hear it from us before the trafficker sees the rejection.