Direct answer
ASO work compresses badly: keyword research done the week of launch produces a keyword-stuffed title, and screenshots designed after the build freezes produce five frames of the same claim. A four-week pre-launch timeline spreads the work in dependency order β research and positioning first, metadata second, creative third, QA and freeze last β so each stage reviews the previous one instead of improvising it. Week 1 locks positioning and keyword clusters; week 2 turns clusters into title, subtitle, keyword field, and description drafts; week 3 produces the screenshot recipe and localized creative; week 4 runs the pre-submission QA pass and freezes the package with one owner. The timeline's real function is not the calendar β it is forcing the decisions that everything else depends on to happen while they are still cheap to change.
The four-week map
| Week | Stage | Output | Gate to pass |
|---|---|---|---|
| 1 | Research and positioning | Positioning statement, keyword clusters with owner fields | Team agrees on one primary promise |
| 2 | Metadata drafting | Title, subtitle, keyword field, descriptions per store | Clusters placed; claims verified |
| 3 | Creative production | Screenshot recipe, designed frames, localized variants | Sequence proves the metadata promise |
| 4 | QA and freeze | Reviewed package, submission candidate | One owner signs off; edits stop |
Recommended flow
Week 1: decide before drafting
Lock the positioning statement β who the app serves, what outcome it improves, why this release matters β and run keyword research to clusters with assigned fields. Everything downstream is cheaper because these decisions stop moving. If positioning is still contested on Friday, extend week 1 rather than starting metadata on sand.
Week 2: metadata from clusters, not from a blank page
Draft title and subtitle from the primary clusters, build the keyword field from the leftovers, and write store-specific descriptions. End the week with a claims audit against the current build so week 3 designs screenshots for verified promises only.
Week 3: creative that proves the metadata
Write the screenshot recipe first β role, proof point, and copy hierarchy per frame β then design. Localized variants are produced in the same week from the same recipe, not discovered as a gap later. The gate: someone who did not write the recipe confirms the sequence proves the title's promise.
Week 4: QA, freeze, and buffer
Run the pre-submission checklist: claims, screenshots against the release candidate, keyword-field audit, locale consistency. Then freeze β one owner, no post-QA edits. The remaining days are buffer for what QA finds, which is the reason QA cannot happen on submission day.
Compressing the timeline
Smaller releases can compress stages but not their order: research before metadata, metadata before creative, QA after everything. A two-week version halves each stage; a two-day version is a re-verification pass over existing assets β reusing last release's research is fine, skipping the QA gate is not.
Common failure modes
Creative starts in parallel with research
Screenshots designed while positioning is still moving get redesigned or, worse, ship proving an abandoned promise.
The freeze is soft
If "frozen" metadata keeps accepting improvements, week 4 QA guarantees nothing about what actually ships. A freeze without an owner who can say no is a suggestion.
The timeline exists only for the flagship launch
Every metadata-touching release deserves the compressed version of the same order. Rankings are lost in routine updates where nobody re-checked what the subtitle now claims.
Pre-launch checklist
- Positioning statement and keyword clusters locked before any drafting.
- Metadata drafted from clusters, claims audited against the build.
- Screenshot recipe written and reviewed before design begins.
- Localized variants produced inside the creative week.
- Pre-submission QA completed with days of buffer remaining.
- Package frozen by one named owner.
Operating rule
Any stage may be shortened; no stage may be reordered or skipped. If launch pressure forces a cut, cut scope β fewer screenshots, fewer locales β never the QA gate.
Why this matters in App Store Helper
App Store Helper structures a listing project in the same dependency order: positioning and keywords feed metadata drafts, metadata feeds the screenshot recipe, and review checkpoints mark each gate. The four-week timeline becomes visible project state β what is locked, what is in review, what is frozen β instead of a calendar someone maintains by hand.