Create one manifest row per destination
A store listing, social post and landing-page embed can need different footage or endings. Give each row an owner, export revision and acceptance condition before editing.
This example uses a fictional habit app launching a weekly summary. Suppose iOS is ready while Android support is pending. Preserve that distinction; a development screen is not proof of universal availability.
Confirm the release and audience
Record the capture build and plans, roles, devices or regions that can access the feature. Ask the release owner to confirm rollout details. If availability is unresolved, hold the asset or obtain approval for precisely scoped wording.
Do not invent an Android interface to simplify the message. Keep a truthful fallback: an approved general demonstration, an availability page or a decision to wait.
| Decision or state | Example | Review |
|---|---|---|
| iOS preview | Released weekly-summary build | Review current store guidance. |
| Android listing | Feature still pending | Hold the feature-specific claim. |
| Social clip | Confirmed iOS availability | Verify next step and eligibility. |
| Landing embed | Matches released app | Attach revision-specific approval. |
Review footage, rights and destination rules
Check sample data, notifications, music, faces and third-party assets. Attach approval to the exact export, not a vaguely named folder. Review store destinations against their current official guidance.
Apple and Google Play publish separate preview-asset requirements. A social edit with reaction footage should not automatically become a store asset. Use the linked sources for the specific destination and file.
Rehearse the handoff and hosted review
Have someone identify approved and held rows without help. Open every next-step link in its intended device context. Confirm what an unsupported visitor encounters and who can replace an incorrect export.
This is a proposed tabletop exercise, not a tested customer launch. After release, record the date and verify hosted files separately. Local source review, creative approval and public release are distinct states.
Copy the planning worksheet
Use this worksheet in your own notes. Fill it with verified product details and actual review observations before sharing an asset.
Asset / destination:
Build and capture date:
Eligible devices / plans / regions:
Rights review:
Export revision and approval owner:
Next-step link / fallback:
Held or approved:
Release date / hosted verification:Official references
Requirements and reporting can change. Check the current source for your destination before relying on a specification.
Browse the founder guide library for the next task in your workflow.