An in-house playable workflow needs three roles (a UA manager who owns the data, a creative lead who owns the brief, and an artist who owns the assets), one build tool, a one-page brief, a fixed review and QA step, and a weekly rhythm that ships variants on the same day every week. With the right tool, you do not need a developer in the loop for each version. The rest is discipline: names you can read in a dashboard, and a testing cadence you keep when things get busy.
Should you bring playables in-house at all?
Check this first. If you test fewer than three or four playables a month and have no creative team, an agency is usually the better deal. In-house pays off when volume is high enough that waiting on someone else's queue costs more than doing it yourself. AppAgent puts the line at about five playables a month. We break the decision down in in-house vs agency vs freelancer. This page assumes you have decided to build the loop.
Who do you need on the team?
| Role | Owns | Time per week (rough) | Often already on staff as |
|---|---|---|---|
| UA manager | Which playables run, budgets, reading results, calling winners and losers | A few hours | UA or performance marketing |
| Creative lead | The brief, the hypothesis per variant, final review for brand and clarity | Half a day to a day | Creative strategist, marketing art lead, video lead |
| Artist | Assets, hooks, end cards, visual polish inside the tool | Two to three days | Marketing artist, motion designer |
| Developer (optional) | Custom mechanics, engine exports, tracking events | Depends on the route | Game team, usually busy |
The developer row is the one that decides your speed. If every version needs code, the developer's calendar is your testing cadence. Teams we talk to often have the HTML5 skills in the building, but those people also ship the game, and the game wins every priority call. Plan for that, not against it.
Which tools does an in-house team need?
Four slots. Fill each one once and stop shopping.
One brief in, a network-ready playable out. Genie Playable builds a playable from your APK or HTML build plus the assets in Genie, from a format that's already working, or from scratch from a brief to Genie Agent. The next version starts from the last one. No developer needed at any step.
Try GenieWhat goes in a playable brief?
One page. If the brief does not fit on one page, it is two playables. Copy this template.
| Field | What to write | Example |
|---|---|---|
| Name | Using your naming convention (below) | MATCH_ALL_FarmRescue_v01_base |
| Hypothesis | One sentence: what you change and what you expect | A fail state at second 12 will raise CTR versus the always-win version |
| Parent | Which playable this is a variant of, or "new concept" | MATCH_ALL_FarmRescue_v01_base |
| Hook (first three seconds) | What the player sees before touching | Flooded farm, timer running |
| Core interaction | The one thing the player does | Swipe to match three, drains water |
| Win or fail | How the moment ends | Near miss, one move short |
| End card | Message and CTA | "Save the farm" plus store button |
| Assets | Links to approved files | Folder link |
| Networks | Where it will run | AppLovin, Unity Ads, Meta |
| Success metric and stop rule | What you will read, and when you stop | IPM and CTR vs parent after a set spend |
The hypothesis line is the one teams skip, and the one that matters most. A variant that changes the hook, the difficulty and the end card at once can win, but you will not know why. One change per variant. For the structure of each part, see the anatomy of a playable ad.
How should the review loop work?
Two reviews, both short, both with a named owner.
Keep stakeholders out of the build-time loop. A playable that waits a week for someone senior to look at it has already lost most of its value. Agree on brand guardrails once, write them down, and let the creative lead sign off against them.
How do you QA a playable for each network?
Every network has its own rules for file size, file format, how the store button is wired, and what the playable may load. A build that passes on one can be rejected on another. Run this checklist on every export:
Specs by network are in our specs hub. A rejection on a Friday launch usually means the variant goes live the following week, so QA on Thursday, not Friday morning.
How should you name playables?
So that anyone can read a dashboard row and know what it is, and so you can sort winners by concept. A format that works: GAME_NETWORK_Concept_vNN_change
Rules: the concept name never changes; the version number always goes up; the last part names the single change. Use ALL when the same creative ships to every network and a network code when it differs. Keep a simple log (a sheet is fine) with name, parent, hypothesis, launch date, networks and result.
How often should you test new playables?
Set the cadence by spend and fatigue, then hold it. Most teams we talk to run a mix of a small number of new concepts and a steady flow of variants of whatever is winning, because variants are cheaper to make and faster to learn from. Our guide on how many playables to test gives volume ranges by budget, and how to A/B test playable ads covers test setup and when to call a result.
What does a weekly playable rhythm look like?
| Day | What happens | Owner |
|---|---|---|
| Monday | Read last week's results. Call winners, losers and "keep running". Flag fatiguing playables. | UA manager |
| Tuesday | Write briefs: variants of winners first, then new concepts. One hypothesis each. | Creative lead with UA |
| Wednesday | Build. Artist and creative lead work in the tool; developer only for custom work. | Artist, creative lead |
| Thursday | Creative review, fixes, network exports and QA on devices. | Creative lead, artist |
| Friday | Go-live review and launch, so tests gather data over the weekend. | UA manager |
The point of a fixed rhythm is that nobody has to ask "when is the next batch?" The answer is always Friday. When a winner fatigues midweek, its replacement is already in Tuesday's briefs. To check whether a playable is underperforming or just early, see is my playable ad working?
What usually breaks an in-house workflow?
Exports per network from one source. Genie Playable exports optimized builds for Meta, AppLovin, Unity Ads, Liftoff, Google Ads, TikTok Ads, Pangle and Mintegral, with Moloco coming soon. Your Thursday QA becomes a check, not a rebuild.
Book a demoWhere does Genie Playable fit?
Genie Playable is the build tool in this workflow. Your artist and creative lead build playables from your game's APK or HTML build plus the assets in Genie, from a format that's already working, or from a brief to Genie Agent, and make the next variant from the last version without a developer. Self-serve starts at $490/month, or $249/month for startups, with a free sign-up that covers your first two playables. Larger teams usually start with a custom plan: a one-month pilot where the Genie team onboards you and helps build the playables you want, which is a practical way to set up the rhythm above with support.
Who it is not for. Teams that want a fully managed service with no internal creative owner, teams that need a fully custom 3D mini-game built from scratch, and teams that test a playable once a quarter. For those, a studio or agency is the better route.
Set up the loop once, then run it every week. Try Genie on your game, or book a demo to start with a guided pilot.
Try Genie