Ask a team that ships playables regularly where the time goes and almost nobody says building. It goes into waiting for an asset, rebuilding after feedback that arrived late, working out which of four files is current, and chasing an approval that keeps almost happening. Production is the fast part; the process around it is where schedules die.
The handoff that causes most rework
Between whoever decided what the ad should be and whoever builds it. A brief that names a game and a palette leaves the builder guessing the win state, the session length and the CTA moment, and those guesses return as change requests one round at a time. The fix is not a longer brief but a more decisive one — settle the mechanic, the ending, the timing and the target networks before anyone opens an editor.
The second handoff is assets. "The art is coming" is where a two-day build becomes a two-week one. Listing what exists and what does not, with an owner and a date against each gap, converts an unknown into a task.
Review by screenshot is the core problem
A playable is an interactive artefact and a screenshot is not. Reviewing one by static image produces feedback about colours and copy — the things visible in a still — and almost none about pacing, difficulty, responsiveness or whether the interaction is legible, which are the things that determine whether it works.
Worse, it produces false confidence. A stakeholder who approved a screenshot has not approved the ad, and the gap surfaces after launch when the pacing turns out to be wrong. Anyone whose sign-off matters needs to play the build on a phone, and the practical way to make that happen is a link they can open rather than a file they must side-load.
The single highest-leverage change
Replace "here are some screenshots" with a shareable link that runs the real build on the reviewer's own phone. It converts feedback from opinions about appearance into observations about experience, and it usually removes an entire round.
Version sprawl and how it starts
It starts with a duplicate. Someone copies the project to try an alternative end card, the alternative is better, and now there are two projects that share ninety per cent of their contents and diverge slightly with every subsequent edit. Three weeks later nobody can say which one has the corrected store URL.
Two habits prevent it. Name variants for the variable under test rather than for their sequence — hook-a and hook-b rather than v3 and v3-final — so the name says what the difference is. And keep one project as the trunk from which variants are cut, so a fix to the store URL happens once and propagates rather than needing to be applied to five files by hand.
Version history helps here in a way that copies do not: a named snapshot before a risky change lets you experiment inside one project instead of forking it, which is the behaviour that creates the sprawl in the first place.
What to agree before each review round
A review round goes faster when reviewers know what they are judging. Send the link with three short notes: what this round is for (pacing, copy, or final sign-off), which device and orientation to try it on, and what is already settled and not open for comment — the brand colours the client supplied, say, or the mechanic agreed in the brief. Without that third note, every round reopens the decisions of the one before it.
Approval that actually terminates
The most common approval failure is that nobody defined what approval means or who gives it. Feedback arrives from four people, some of it contradictory, none of it explicitly final, and the builder makes a judgement call that a fifth person reopens two days later.
What works is unglamorous: one named approver, one round of consolidated feedback, and an explicit statement of what is still open. If a stakeholder wants input, they give it in the round; if they miss the round, their input goes into the next creative rather than this one. That sounds rigid and it is the only thing that reliably converts an open-ended review into a shipped file.
Feedback that a builder can act on
"Make it more exciting" is a feeling, not a change. The translation into something buildable is usually one of four things: the first interaction takes too long to become available, the reward feedback is too quiet, the difficulty curve is flat, or the end card arrives after the interest has passed. Teams that learn to give feedback in those terms cut their revision rounds roughly in half, because each round changes something specific rather than something interpretive.
It helps to ask reviewers for the moment rather than the fix. "I lost interest around six seconds" is far more useful than "add more particles", because it identifies where the problem is and leaves the solution to the person best placed to choose it.
Where client work differs
Two things change with an external client. Approval needs to be recorded rather than remembered, because a disagreement about what was signed off is a commercial problem rather than an internal one. And the client usually needs a review surface that does not require them to have an account in your tooling — a link that opens on their phone, shows the real build, and collects comments in one place.
The second point is worth designing around deliberately. Every extra step between a client and the thing they are approving adds delay, and the most common cause of a stalled sign-off is simply that the client could not easily look at it.
A worked example: two rounds instead of five
Picture a client project for a puzzle game. Round one goes out as a rough build with placeholder art and a note saying the round is about pacing only. The client plays it on their phone and reports losing interest while waiting for the second board — a moment, not a fix. The builder shortens the wait and swaps in the final art, and round two goes out as a sign-off round to the same named approver. Two small copy changes come back, are made, and the approver confirms in writing. The file ships.
The difference from a typical five-round project is not how fast anyone built. It is that each round had one purpose, one approver and one consolidated reply, so nothing came back that had already been settled.
A workflow that fits on one page
- Brief settles mechanic, ending, timing, networks, orientation and assets. One page.
- Assets confirmed present or assigned with an owner and a date.
- Build the rough version and play it before polishing anything.
- Internal round: play on a phone, feedback in terms of moments rather than fixes.
- Client or stakeholder round: one link, one named approver, one consolidated set of notes.
- QA on real devices, both platforms, both orientations, correct store links.
- Export per network, check each against that network's requirements, ship.
The order matters more than the detail. Most of the rework in playable production comes from doing step three after step five — polishing something whose pacing had not yet been agreed.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker