Launch Day Is the Beginning, Not the Finish Line
I have been releasing solo-built apps for twelve years. Since Rork came along, the time it takes to ship something has dropped dramatically — ideas I used to abandon now make it to the store. But that has only made the post-launch 90 days feel more important, not less.
The real value of an app is decided after release. Crashes, reviews, ad revenue, feature decisions, monetization timing, retention — get any one of them wrong and the app you spent weeks crafting fails to gain altitude. Apps built with Rork are no exception. In fact, because generative AI lets us ship faster, the operational decisions that follow launch are what actually distinguish a hit from a quiet release.
This article walks through eight decision branches that come up in the first 90 days after launching a Rork app, drawn from my own operations notebook. I hope it helps you avoid hesitation when those branches show up in your own work.
Decision 1 — How Much to React to Crash Reports
The first few days after launch flood your dashboard with crashes. OS variations, rendering glitches on specific devices, edge cases when the network drops — things you could not have anticipated during development.
The key is to avoid treating every crash with equal urgency. The triage I use today:
- Hotfix immediately: launch crashes, crashes during the purchase flow, crashes on operations that affect reviews
- Next release: feature-specific crashes that are infrequent and have a workaround
- Observe only: single-device, single-OS crashes that are not reproducible
For hotfix tier I aim for 48 hours from detection to release. With Rork the rebuild and resubmission cycle is fast enough that, if you time the App Store review queue well, this is realistic.
Spending hours on "observe only" crashes pushes feature work back, and users churn. Getting the priority right is what determines your operational throughput in the launch period.
Decision 2 — When to Start Replying to App Store Reviews
Reply work eats time. Five minutes per reply, fifty replies per day, and you have lost four hours.
My rule is no replies for the first 14 days. Early reviews come from a user mix that has not yet stabilized, and your replies will look stale once your audience solidifies. Instead, I log every review and treat it as raw material for the next improvement plan.
From day 15 onward I reply by these rules:
- 1–2 stars: always reply, with concrete improvement plans if applicable
- 3 stars: reply only when there is a constructive feature request
- 4–5 stars: reply if there is a specific request or comment; thanks-only reviews can be skipped
Without this line, replies eat into development time. The principle to internalize is: replies are lower priority than improvements.
Decision 3 — When AdMob Revenue Lands, Should You Change Strategy?
Around day 30, your AdMob numbers stabilize enough to be informative. Whether your daily revenue is in yen-hundreds, yen-thousands, or yen-tens-of-thousands changes what you should be doing.
The bands I use:
- Under ¥1,000/day: prioritize usability over monetization. Do not add ad slots
- ¥1,000–10,000/day: tune ad placement and run new-user acquisition in parallel
- Over ¥10,000/day: consider adding 1–2 ad slots and invest in expanding core features
The exact thresholds depend on your portfolio, but the principle — different revenue ranges call for different actions — is broadly applicable. Don't react to day-1 numbers; reason on a 30-day window.
A practical note: even an app earning under ¥1,000/day, multiplied across five apps in a series, becomes ¥5,000/day. Running several steady apps is more realistic for solo developers than chasing one breakout hit.
Decision 4 — New Features vs. Sharpening Existing Ones
It's tempting to think about "what to add next." This is a trap. Sharpening existing features tends to produce revenue faster than adding new ones.
The metric I lean on is the retention delta per feature. With Firebase Analytics or similar, compare day-7 retention between users who used Feature A and users who didn't. Polish the features with the largest deltas first.
Example: in a wallpaper app, "favorites" users had 65% day-7 retention vs 28% for non-users. Making favorites easier to find moved overall retention more than adding a new feature would have.
New features feel exciting, but the highest ROI is usually in the features people are already using. The first 90 days is the right time to invest in polish, not breadth.
Decision 5 — When and How to Add Monetization
Whether to ship monetization at launch or add it later is a question worth answering deliberately. For Rork-built apps I use these patterns.
Ship monetization at launch when:
- The app is a utility used only 1–2 times a month
- The user base skews toward many light users with few heavy ones
- Content needs continuous additions to stay valuable
Add monetization after launch when:
- Initial usage patterns are hard to predict and you want to observe behavior
- You're combining ads with monetization and want to measure ads alone first
When adding monetization later, keep the first implementation as simple as possible. Complex plan ladders or annual/monthly bundles can wait for data. Start with one clear value proposition: "remove ads," "unlock everything," or similar.
Decision 6 — When to Start A/B Testing
Many developers want to A/B test from day one. A/B tests with low user counts are not informative. With 100 daily installs, a 5% lift from changing a button color could easily be noise.
I begin treating A/B test results as decision input only once daily active users exceed 1,000. Until then, I rely on intuition plus interviews with a few users.
What you should do at launch is not A/B testing but hypothesis curation: write down what you intend to change next, and why you believe it will help. Once user counts grow, you'll be ready to design meaningful experiments quickly.
Decision 7 — How Much Time to Spend on Store Listing Optimization (ASO)
Screenshots, icons, descriptions — ASO has high upside and unlimited time-sink potential.
My rule: don't aim for perfection in the first 30 days. Run with the assets you launched with, collect 30 days of conversion data (impression → install), then update in this priority order:
- Icon (highest impact, easiest to misjudge)
- First screenshot
- App name and subtitle
- Remaining screenshots
- Long description
In particular, iterating the icon 2–3 times at one-month intervals is worth doing. It's not unusual to see 30–50% install-rate swings from icon changes alone, on the same app.
Decision 8 — Start the Next App, or Stay With This One?
Around day 90, the next idea starts whispering. Rork makes shipping fast enough that the temptation is real. But abandoning the growth of the current app to start a new one usually leaves both half-finished.
The criteria I use to decide whether the current app can run with reduced attention:
- Day-7 retention is above 30%
- Daily installs are stable (within ±20%)
- Critical crashes have been resolved
- A revenue path (ads or monetization) is functioning
If all four hold, I allocate roughly 8 hours/month of maintenance to the current app and reallocate the rest of my time to the next app. If they don't, the priority is bringing the current app to that state before starting anything new.
The rule for running a portfolio of apps is: reach a "hands-off" state before starting the next one. Adding apps you cannot let go of just stacks operational load.
At 90 Days, Can You See Your App Objectively?
The eight decisions above are not glamorous. They aren't dramatic features or bold pivots. But whether you can see your app objectively at the 90-day mark determines what the next year looks like.
By day 90, ideally you can:
- Name three strengths and three weaknesses in your own words
- List five prioritized things to do in the next 30 days
- Run minimum operations without daily intervention
When those three are in place, ongoing operations get dramatically lighter. When they aren't, you are still inside the post-launch fog and shouldn't pretend otherwise.
Rork makes building fast, but operating an app takes about as much time as building it. Carve out as much time for operations as you do for development. Twelve years in, that is the single biggest secret I would pass on to anyone wanting to keep going as a solo app developer.
If even one of these eight decisions becomes useful in your own operations tomorrow, this article will have done its job.