An app-launch asset checklist that catches dependencies before export.

Start with the release, not the export list

Write the release version, intended markets, languages and launch dependencies at the top of the asset plan. Name the person who confirms which features are available. A screen recording can look polished and still misrepresent the product if a feature has changed since it was captured.

List what is ready, what needs updating and what must not appear. Include approved demo accounts and a privacy check for recordings. Real customer names, emails, payment details and private workspace content do not belong in a marketing demonstration.

This checklist helps organize app-launch creative. It is not an app-store submission, localization, tracking or development service. Assign those responsibilities explicitly rather than assuming the editor owns them.

Give each asset one destination and one job

The same source recording may help create several assets, but the same finished video should not be assumed suitable everywhere. Check each destination’s current dimensions, duration limits, audio rules, interface-safe areas and permitted content before production. Store previews and paid ads have different purposes and may have different restrictions.

Worked example: a feature is ready, but the launch is not

Hypothetical release-planning example. The product and statuses are illustrative, not evidence of a Famekite client launch.

A fictional scheduling app has a working conflict warning. Its store screenshots still show an older navigation layout, while the ad draft directs viewers to a signup page with outdated trial wording. The feature is ready; the marketing journey is inconsistent.

1. Product owner: approve a recording of the current conflict-warning flow using demonstration data.
2. Store owner: replace obsolete screenshots and verify current store specifications.
3. Campaign owner: approve wording that matches the real offer and destination.
4. Editor: produce only the agreed versions after those inputs are available.
5. Publishing owner: confirm links and release timing before posting.

Mark an unresolved dependency as blocked, not “almost approved.” A scheduled post does not override a product or legal approval. If the offer changes after an export is signed off, identify every asset carrying the old wording before replacing files.

Use an approval register instead of a chat thread

Give each asset a stable identifier and keep one current status. Store the exact approved version alongside the decision; “looks good” without a filename is hard to audit after several revisions.

• Asset ID and destination: what is being delivered and where it will run.
• Product version: which release the screens and claims represent.
• Source readiness: approved, needs replacement, or missing.
• Claim and rights approval: owner, decision and any limits on use.
• Specification check: platform, date checked and responsible person.
• Export version: exact filename, language and placement.
• Publishing state: not scheduled, scheduled, live, or withdrawn.

Separate approval of the message from approval of the export. A correct script can become an incorrect video through an old screen, a clipped disclaimer or an unreadable caption. Review the actual delivered file on a representative phone before final sign-off.

Define the first useful action before reporting installs

An install, an account registration and a useful product action are different milestones. Ask the product team which event indicates that someone has reached the intended value. Then assign a tracking owner and verify the event before making performance claims.

For the fictional scheduling app, creating a schedule could be a candidate event, but the team must decide the actual definition and business relevance. Do not copy an event name from this guide and treat it as validated measurement. Keep attribution limitations, reporting periods and channel context with any result.

Creative production alone does not establish whether acquisition is profitable. If a campaign gets attention but users cannot complete onboarding, check the product journey rather than asking for a more aggressive promise in the ad.

Run a release-day consistency check

1. Open the ad destination, landing page and store listing as a visitor would.
2. Confirm the offer, feature claims and available release agree.
3. Play exported videos with sound on and off; inspect text and important interface details.
4. Check that permission and approval records cover the intended publishing use.
5. Verify who can pause or replace a wrong asset after publication.

The App Launch Asset Map in the verified-email pack helps organize destinations and ownership. Use it alongside this guide, not as platform certification or launch clearance. For a quote, bring the release status, approved screens and destination list to the app-launch scope checklist.

Before you brief us