Pre-Launch App Marketing: 30-Day Playbook Before You Ship
Most launches under-perform because marketing starts at launch. The 30 days before launch are when most of the leverage actually lives. Here is the playbook.

Why does pre-launch marketing matter more than launch day?
Most app launches under-perform for a predictable reason: marketing starts on launch day, by which point the foundational decisions that determine the outcome are already locked in and irreversible inside the launch window. ASO, MMP setup, analytics wiring, retention loops, waitlist size — none of these can be meaningfully fixed in the 72 hours when ranking algorithms are deciding whether to feature your app.
Apps that win on launch week look fortunate from the outside, but they almost never are. They had 30+ days of disciplined pre-launch work — most of it invisible to outsiders — that compounded into the launch result. The teams that ship on a deadline without that 30-day groundwork are gambling thousands of dollars of paid budget against an algorithmic ranking system that does not reward improvisation.
Install velocity is the heaviest weighted signal in both store ranking systems for new apps. Google Play's own launch best practices documentation explicitly references velocity as a discovery driver, and Apple's editorial team uses similar momentum signals to decide which apps to feature. A scattered launch that trickles installs across two weeks moves neither algorithm. A concentrated launch that fires 10,000-50,000 installs in 72 hours triggers both.
Across 300+ apps in our portfolio since 2013, the variance between a well-prepared launch and a rushed one for the same product is consistently 5-10x in first-30-day installs and 3-5x in first-90-day revenue. The product is the same. The 30 days of preparation is what separates the outcomes. This is the playbook we use with clients.
Day 1-7: How do you set up your foundation?
The first week of pre-launch is entirely about infrastructure — the systems you cannot bolt on later once paid traffic and real users are flowing. Five priorities, none of them optional:
- Set up your MMP (AppsFlyer, Adjust, or Singular): Configure SKAdNetwork conversion values, deep link routing, and fraud rules. iOS attribution without SKAdNetwork properly mapped means you cannot optimise paid campaigns post-launch — you are flying blind. We have audited dozens of apps where misconfigured SKAdNetwork postbacks invalidated the first 30 days of paid spend data.
- Define your in-app event taxonomy: install, registration, key activation event, first purchase or subscription start, deep engagement (D7 active, level 10 reached, etc.). Track all of them from day one. Adding events post-launch breaks cohort comparison and ruins your ability to evaluate channel quality.
- Wire your analytics dashboard: Mixpanel, Amplitude, or RudderStack — pick one and instrument the full funnel from install to monetisation. According to AppsFlyer's State of App Marketing report, apps with structured event tracking from day one show 40-60% better D30 retention than apps that add tracking ad-hoc.
- Lock down ASO foundations: Keyword research, first draft of title, subtitle, long description, and final icon. See our complete ASO guide for the full keyword-research workflow. This is also the week to decide your ongoing ASO operating cadence post-launch.
- Identify your launch tentpole: Is there a date, season, conference, or news moment to time launch around? A tentpole launch consistently outperforms a launch in a vacuum. Even a self-created tentpole (a CEO keynote, a partnership announcement) gives press and influencers a reason to write.
If any of these five are not complete by end of week 1, push your launch date. Trying to compress foundation work into week 2 collapses the rest of the schedule.
Day 8-14: How should beta and waitlist work together?
Week 2 is when you stop building in isolation and start collecting real user signal — the beta surfaces product issues, the waitlist surfaces demand signal, and the two together de-risk the launch. Skipping either is the single most common cause of catastrophic launch weeks.
- Launch TestFlight (iOS) and Open Beta (Android): Invite 200-500 users with diversity across device tiers, geographies, and behaviour types. A homogeneous beta cohort produces homogeneous feedback and misses 60-70% of launch-blocking bugs. Use beta to test onboarding completion rate, D1 retention proxy, and crash-free user percentage — these are the metrics that predict launch-week performance.
- Build the launch waitlist landing page: Single page, sharp value proposition, email + optional phone capture, social share incentive (early access, lifetime discount, badge). Keep it lightweight — heavy waitlist pages convert worse and signal less to the algorithm-driven channels you will use to drive signups.
- Drive waitlist signups via concentrated organic channels: founder posts on LinkedIn and Twitter/X (thread format outperforms single posts 3-5x for app teases), IndieHackers Coming Soon, Product Hunt Coming Soon, 3-4 relevant subreddits (concentrated, not spammed), niche Discord communities, and 2-3 micro-influencer pre-launch teases. Avoid paid waitlist acquisition unless the unit economics make sense — paid waitlist signups consistently convert worse than organic at launch.
- Capture beta feedback in a structured way: bug reports, friction logs, retention drop-off points, monetisation objections. An unstructured beta produces vibes; a structured beta produces a fix list.
- Iterate the product before launch. A launch with a known-bug-fixed product beats a launch on the original schedule with a broken product, every single time. Postponing launch by 7-10 days to fix critical beta findings is almost always the right call.
The waitlist does not need to be enormous. In our portfolio, even 500-2,000 highly engaged waitlisters routinely drive enough launch-day velocity to trigger category ranking lift. Quality and engagement of the waitlist matters far more than absolute size.
Day 15-21: What does ASO and paid prep look like?
Week 3 is when ASO assets get finalised and paid campaign infrastructure gets built — both need 7-10 days of lead time to be ready for launch day. This is also the last realistic window for editorial featuring submission, which has a hard 4-6 week review cycle.
- Finalise screenshots (5 minimum, 10 ideal): Test 2 first-screenshot variants against your beta cohort for early conversion signal. Apple's Custom Product Pages let you serve variant creative to different paid traffic sources from day one — set up at least 3 variants for different audience segments.
- Record your preview video: 30 seconds maximum, with the value proposition landing inside the first 2 seconds. Both stores autoplay video on the store page; a weak opening costs you the install decision before users even read the copy.
- Submit for Apple and Google editorial featuring: 4-6 week lead time. Apple's editorial team accepts pitches via App Store Connect; Google has a similar nomination flow inside Play Console. This is your last realistic window — submissions after day 15 will not be reviewed in time for launch week.
- Pre-build paid creative inventory: 8-12 creatives ready to launch on day 0. Mix of UGC-style video, motion graphics, and static. Apps launching with 2-3 creatives consistently see 60-80% higher CPIs than apps launching with 8-12 — the algorithms in Google App Campaigns and Meta Advantage+ need creative volume to optimise. See our fastest way to get installs playbook for creative testing protocols.
- Set up paid campaign structures: Google UAC and Meta Advantage+ accounts ready, pixels firing, audiences saved, geographic splits configured (especially India Tier-1 vs Tier-2/3 — auction prices differ 2-3x). See our user acquisition service overview for our campaign setup checklist.
- Brief 5-10 micro-influencers for launch-week posts: coordinated firing inside a 48-hour window beats sequential posts spread across two weeks. Use the influencer push to manufacture the velocity signal stores reward.
One pattern we see repeatedly in our portfolio: teams that treat week 3 as "buffer time" for product polish almost always under-prepare paid and ASO. The product polish never feels finished; the marketing infrastructure that determines launch outcome gets sacrificed. Protect this week ruthlessly for marketing prep.
Day 22-28: How do you reach launch readiness?
Week 4 is execution and contingency planning — final build submission, press outreach, support readiness, and load testing. The work that does not happen this week will hit you during launch week, when you have no bandwidth to address it.
- Submit final app build with 1-week buffer: Apple and Google review times vary wildly (24 hours to 7+ days). Submitting on launch-eve has caused more delayed launches than any other single factor. Build the buffer in. Read Apple's App Store Review Guidelines end-to-end one more time before submission to avoid avoidable rejections.
- Press and PR outreach: reach out to TechCrunch, YourStory, Inc42, The Ken, and 5-10 relevant niche publications. Embargo to launch day. Send a tight one-page brief with screenshots, founder quote, and a clear "why now" angle. Generic press blasts get ignored; sharp story angles get covered.
- Product Hunt launch prepared for Tuesday or Wednesday of launch week. Hunter identified (ideally someone with 5K+ followers in the relevant category), 30+ supporters lined up to upvote in the first hour. The first hour determines whether you crack the top 5; everything after compounds from that.
- Email sequence ready for waitlist: pre-launch teaser email (T-2 days), launch announcement (launch morning), post-launch follow-up with first-week feedback (T+5 days). Pre-write all three; do not try to write them during launch week.
- Customer support readiness: help centre articles published, support email actively monitored, in-app feedback channel live, escalation paths for payment and account issues defined. A 1-star review on launch day for a support issue is a permanent ranking weight.
- Load testing at 10-20x expected launch-day traffic: servers, payment processing, analytics ingestion, push notification delivery. A launch that goes viral but crashes the backend produces the worst possible outcome — peak visibility paired with peak bad reviews.
In our portfolio, the launches that go cleanest are also the most rehearsed. The teams that win run a tabletop exercise in week 4 — walking through the launch hour by hour, identifying single points of failure, assigning owners. The hour you spend rehearsing prevents a day of firefighting on launch day.
What does launch week itself look like?
Launch week is execution, not strategy — the strategy was set in the preceding 28 days. The single biggest determinant of launch-week outcome is how tightly coordinated the various pushes are inside the first 6 hours.
- Launch Tuesday or Wednesday: avoid Monday (people in inbox catch-up mode) and Friday (weekend slowdown immediately follows). Tuesday morning is the highest-engagement window across LinkedIn, Twitter/X, Product Hunt, and most press cycles.
- Coordinated 6-hour launch window: email to waitlist sends + embargoed press articles publish + Product Hunt launches + influencer posts go live + paid campaigns activate, all inside the same morning. The velocity stack is what triggers store algorithm lift; spreading the pushes loses the signal.
- Monitor in real time: install funnel conversion rate, crash-free user percentage, payment error rate, customer support volume, review velocity. Have one person dedicated solely to monitoring — not building, not posting, just watching dashboards and surfacing anomalies.
- Respond to early reviewers, press comments, and community discussion in the first 6 hours. Visible founder engagement multiplies social proof and converts hesitant reviewers. Per AppsFlyer's Performance Index, apps with founder-visible review responses in week 1 see 15-25% higher D7 review-revision rates.
- Hold creative refresh in reserve for day 3-4: initial creative typically starts fatiguing by hour 48-72 on paid channels. Have your second wave of 4-6 creatives queued and ready to activate the moment CPIs start drifting upward.
- Daily standups for the first 7 days: what is the install number, what is the CPA, which creative is winning, what is breaking, what is the priority fix. Discipline beats heroics during launch week.
The teams that translate launch week into sustained growth treat it as the first 7 days of a 90-day operation, not a discrete event. The work the day after launch is as important as launch day itself.
How do you run the first 30 days after launch?
The first 30 post-launch days determine whether your launch becomes a sustainable product or a one-week spike that disappears. Cohort analysis, fast product iteration, and disciplined paid scaling are the three levers that decide the outcome.
- Daily cohort retention review: D1, D7, D14, D30 by acquisition channel and by creative. The cohorts that beat your baseline retention deserve more budget; the cohorts below baseline deserve immediate creative or audience changes. Do not aggregate channels — bad cohort hides in averages.
- Ship a meaningful product update by day 14: shows momentum to both users and the store algorithms. Both Apple and Google reward update frequency in early-stage app ranking signals. Even a small feature plus 5-10 bug fixes counts.
- Begin ASO iteration based on real install data: screenshot A/B tests, subtitle variants, keyword opportunities surfaced by actual search behaviour. SplitMetrics research shows the highest-leverage ASO iteration happens in the first 60 days post-launch, when search behaviour is still settling.
- Scale paid spend based on cohort LTV signals: channels and creatives delivering above-target LTV get 2x budget weekly; underperformers get paused. Resist the temptation to scale on install volume alone — installs without LTV alignment burn capital and pollute store quality signals.
- Build reactivation campaigns for lapsed users: push notifications, email, and re-engagement paid ads targeting users who installed but did not complete activation. Reactivation typically delivers 3-5x lower CPA than fresh acquisition.
- Document lessons systematically: what worked, what failed, what to do differently next launch. The teams that compound across launches are the teams that write down what they learned each time.
If launch week is the spike, the first 30 post-launch days are the slope. A spike with a flat slope tells the algorithm you are a flash in the pan; a spike with a rising slope tells it you are a category contender. The post-launch operating cadence is what separates the two.
For deeper post-launch playbooks see our guide to getting your first 10K installs and our case studies in portfolio results. Talk to our team if you want a pre-launch audit or full managed launch for an upcoming app.
Frequently Asked Questions
How early should pre-launch marketing start?+
Minimum 30 days. Ideally 60-90 days for a serious launch — gives time for editorial featuring submission, deeper beta cycles, and a larger waitlist build.
Is Product Hunt worth doing for India-targeted apps?+
For B2B SaaS, developer tools, and global-target consumer apps — yes, high leverage. For India-only mass-consumer apps — limited; concentrate on India-specific channels like regional creators, IndieHackers India, and relevant subreddits.
How big should a launch waitlist be?+
5,000-15,000 emails is realistic for most pre-launch periods. 50,000+ is enviable. Even 500 highly engaged waitlisters can drive a meaningful launch-day install spike if engagement quality is high.
Should I open paid ads on launch day?+
Yes — paid plus organic launch-day combined drives the install velocity that triggers store ranking algorithms. Saving paid for week 2 misses the velocity window and wastes the press and influencer pushes that hit on day 1.
What is the single biggest pre-launch mistake?+
Treating ASO and analytics setup as launch-day work. Both need to be locked at least 7-14 days before launch — trying to wire them post-launch corrupts your data and ranking signals during the most important week.
How many beta testers do I need before launch?+
200-500 active beta testers across diverse device tiers and geographies. Fewer than 200 misses launch-blocking bugs; more than 500 typically produces diminishing signal-to-noise return for most app categories.
When should I submit my final build for review?+
At least 7 days before launch day. Apple and Google review times vary from 24 hours to over a week; the buffer protects you from review-cycle delays derailing launch coordination.
Sources
- Google Play — Launch Best Practices — Official Google documentation on launch checklist and install velocity as a ranking signal
- Apple App Store Review Guidelines — Required reading before submission to avoid common rejection causes
- Apple Custom Product Pages — Variant store-listing creative for different paid traffic sources from day one
- SKAdNetwork Documentation — Apple iOS attribution framework — required for paid campaign measurement post-ATT
- AppsFlyer State of App Marketing — Industry data on event tracking maturity vs retention outcomes
- AppsFlyer Performance Index — Quarterly benchmarks for launch-week and retention performance by category
- Google Ads — App Campaigns Help — Official UAC setup, bidding, and creative volume guidance
- SplitMetrics ASO Research — A/B test research on post-launch ASO iteration leverage in the first 60 days
About the author
Amol Pomane — Founder, Vmobify
Amol leads Vmobify, a mobile app growth agency that has driven 30M+ downloads and ranked 54K+ keywords across 300+ apps since 2013. He writes about ASO, paid user acquisition, retention, and the operational reality of scaling mobile apps in India and global markets.
Free Growth Audit
See exactly how to scale your app with 13+ years of expertise behind you.
Get My Strategy

