The week after launch is where most indie apps quietly die — not from bad code, but from the developer panicking, shipping too many random updates, or chasing reviews. Here is a steadier playbook for the first 90 days.
Background
Launch day brings a flood of low-quality signal: a few downloads, maybe one review, a slight ranking bump. New developers over-react to all of it. The right post-launch posture is to slow down, measure the few metrics that matter, and ship deliberate updates on a weekly or bi-weekly cadence. The App Store rewards consistency more than speed — apps that ship reliable updates with clear release notes outperform those that ship 5 panic releases in week one.
How to tell
- Your app has been live on the App Store for less than 90 days.
- You are feeling pressure to constantly ship, respond, or change things.
- You have not yet established a release cadence.
- You have less than 1,000 downloads but more than 0.
Quick verdict
In the first 90 days, prioritize: critical bug fixes (within 48 hours), retention measurement (continuous), one feature per 2-week cycle, and ignoring most reviews. Skip vanity metrics entirely.
Step by step
Each step has: specific metric + quantitative threshold + tool action. Have RevenueCat / TelemetryDeck / GA4 / App Store Connect open.
-
Day 0 — analytics must emit data.
Verify:
- [ ] App Store Connect → Trends, installs in last 24h > 0 - [ ] Crashlytics / TelemetryDeck / Sentry shows non-zero sessions - [ ] Custom events ("app_open", "onboarding_complete", "first_action") all firing - [ ] Push token registration > 70% (if you use push) - [ ] IAP tested in sandbox; first real-world purchase observedAny zero → fix today. Every later step depends on this signal.
-
D1-D3: crashes only, no other updates.
Thresholds:
crash-free user rate < 99.0% → investigate immediately crash-free session rate < 99.5% → investigate immediately any single stack trace affects ≥ 5% of users → must ship fix within 48hCrashlytics / Sentry entry: dashboard → “Issues” sorted by “users affected”. Top 3 → pull the stack trace, fix directly. Ship fixes via phased release (App Store Connect → Pricing and Availability → Phased Release for Automatic Updates → default 7-day ramp, 1% → 100%).
-
D4-D7: triage reviews.
Rules:
1-star + describes a specific bug → personal reply + backlog ("Fixed in v1.0.2, please update") 1-2 star + subjective complaint ("ugly") → do not reply (sinks emotional energy, won't change rating) 3-4 star + concrete suggestion → personal reply + backlog 5 star → do not reply (don't pad with thanks)Tool: App Store Connect → “Ratings and Reviews” — reply inline. Filter
Country: All+Rating: ≤2. -
W2 — ship first real update (v1.1.x). Based on the first week’s signal, pick ONE:
Priority (in this order): 1. Feature bug affecting onboarding completion ("first_action" fires < 50% = onboarding broken) 2. ≥3 independent users requested the same missing feature 3. Crash fix (recurring sub-top-3 issue) Do NOT: - Overhaul UI (UI doesn't matter until onboarding works) - Add a whole new module (users haven't mastered the current one) - Chase a trend ("add AI", unless a real use case is clear)Ship a numbered release note (see app-store-listing-copywriting step 7).
-
W3-W4: track D1 / D7 retention.
D1 retention (open next day): Industry avg (utility): 30-40% Industry avg (social / content): 20-30% < 20% → onboarding seriously broken > 50% → core promise lands D7 retention (open after 7 days): Industry avg: 8-15% < 5% → core value not working > 20% → ready to scale acquisitionTools:
- Free: TelemetryDeck (privacy-friendly, native Apple, ~$10/month)
- Easy: App Store Connect → Analytics → Retention (lags, but shows trend)
- Powerful: Mixpanel / Amplitude (free tier → ~$25/month)
Screenshot weekly; x-axis = cohort (week N signup), y-axis = D7 retention.
-
W5-W8: core value go/no-go decision.
Decision tree:
if D7 ≥ 10% AND D7 trend rising: core value works → move to scaling rhythm (W8-W12) elif D7 ≥ 10% AND flat / declining: partial fit → run user interviews + funnel analysis elif D7 in 5-10%: weak fit → narrow the audience ("for night-shift nurses" not "for everyone") elif D7 < 5%: no listing-optimization fix → pivot or sunsetUser interviews: pick 5 random active users from the last 7 days (export from RevenueCat / Mixpanel), email them, offer a $10 Amazon gift card for a 20-minute call. Five fixed questions:
1. How did you find this app? 2. After installing, what specifically did you expect it to solve? 3. When you first opened it, what most disappointed or confused you? 4. How often do you open it now? Which exact moment makes you open it? 5. If you had to uninstall today, what would the reason be? -
W8-W12 — establish bi-weekly release cadence. Add a recurring calendar event
Every other Tuesday: ship v1.X.0:2-week cycle: D0 (Tue) Pick 1-3 changes, draft release note D1-D8 Develop + internal QA D9 Internal build review D10 (Thu) TestFlight external (50 testers) D11-D12 Collect TestFlight feedback D13 (Mon) Submit for review D14 (Tue) Approved → phased release startsHard cap: 1-3 changes per release + a theme (“This release: onboarding rewrite”). No 10-item changelogs.
-
D90: real review + decision. Build
90_day_review.md:# 90-day review — <App name> — <date> ## Core data - Total installs: X - D1 retention: X% (industry avg Y%) - D7 retention: X% (industry avg Y%) - D30 retention: X% - Paid conversion (if any): X% - Average LTV: $X - CAC (if running paid): $X ## Channel breakdown | Channel | Installs | D7 ret | Rating | Notes | |---------------------|----------|--------|--------|-------| | Organic search | | | | | | App Store editorial | | | | | | X / social | | | | | | Friends / community | | | | | ## Decision [ ] Commit next quarter, primary focus: <specific direction> [ ] Pivot: keep X, redo Y [ ] Sunset: maintenance only [ ] Walk away: open-source / archivePrimary decision = D7 retention + organic growth trend. Don’t lean on NPS / rating — both are easy to self-deceive on.
Common pitfalls
- Refreshing App Store Connect every hour. Update intervals are slow and the data is noisy at low volumes.
- Responding to every review. Respond to specific bugs and accusations only; ignore subjective negativity.
- Shipping 5 updates in week one because you keep finding small things. Batch them.
- Treating downloads as the success metric. Downloads matter only inasmuch as they produce retained users.
- Buying ads or installs before understanding organic retention. You will burn money on the wrong funnel.
- Letting one bad review derail planning. One review is one data point.
Who this is for
Indie developers in their first 90 days post-launch on the App Store.
When to skip this
Established apps with stable user bases — your iteration framework should be more sophisticated.
FAQ
- How often should I ship updates?: Every 1-2 weeks is a healthy rhythm. Less often and you lose momentum; more often and updates feel chaotic to users.
- What do I do about a one-star review?: If it cites a real bug, respond with a fix ETA. If it is generic (“hate this”), ignore — your response cannot help, and engagement amplifies it.
- When should I start paid acquisition?: After you have 90 days of retention data and know the cost of organic users. Paid before that is gambling.
- How do I know if the app is failing?: 7-day retention under 10% with no obvious explanation is the strongest signal. Crash rate above 1% is the second. Below these, give it time.