Service
Build & Variants
Build the accepted master, then make controlled changes that keep the tested question legible.
Concept illustration · Service stage
Build one accepted master
The master implements the approved interaction, supplied production assets, scoped sound, CTA behavior, responsive layout, and delivery hooks. It is the reference used to judge later variants. Source and build outputs remain identifiable so a reviewer can tell which version was tested.
Keep variants controlled
A qualified variant changes an agreed dimension while preserving the supported master. Useful dimensions include the opening hook, art treatment, timing, difficulty, reward framing, copy, or CTA. Combining several changes can be deliberate, but the test record should say so; it should not be described as a single-variable comparison.
Request | Usually counted as | Why |
|---|---|---|
Swap opening instruction copy | Qualified variant | Same mechanic and implementation path |
Make the first board easier | Qualified variant | Parameter or layout change within the master |
Replace sorting with merging | New master | Core action and state logic change |
Package accepted build for another network | Export | Creative is unchanged; packaging and checks differ |
What the build record should contain
- Master or variant identifier and a short statement of what changed.
- Source revision, build timestamp, language, orientation, and target export.
- Asset and dependency notes, including any remote calls or permissions expected by the runtime.
- Review status, known limitations, and the QA receipt tied to the exact delivered package.
Example production set
An accepted drag-and-sort master can produce six qualified variants: two hooks, two difficulty settings, and two reward treatments. That does not automatically create every possible combination. The variant register should list the exact six builds and their changed dimension. If the buyer later requests a tap-to-choose version, the interaction changes enough to require a new estimate.
Pricing boundary
We quote the number of new masters and controlled variants you need, not a fixed price for each label. Reuse from an accepted master can change the per-creative rate when a batch shares a production system. Asset readiness, mechanic complexity, named networks, languages, review rounds, and delivery cadence shape the written proposal. It states the total fee, deliverables, and price of additional work before production begins.
Common exclusions
Substantial original art, complex 3D, unsupported engine conversion, new core mechanics, and extensive localization are included only when the written proposal names them. Media buying and performance analysis are separate from playable production unless specifically agreed.
Use the scoping worksheet to count masters, variants, and exports before requesting a written scope.