The other night, three days after releasing one of the apps I had built with Rork, I checked the Slack channel I have wired up to App Store and Play Store reviews. There were about thirty new entries waiting for me. Half of them were short variations of "I really like it," and the other half were a tangle of feature requests and bug reports. At the same time, I opened Firebase Crashlytics. None of the reviews mentioned it, but a particular device was crashing in the first few seconds after launch on that very evening, and I stopped scrolling.
The 72 hours right after release are, in my experience, the easiest time for an indie developer to make the wrong call. The volume of reviews pulls you toward shipping features. The Crashlytics numbers tell you to fix something else entirely. Now that Rork has compressed the time it takes to make something releasable, the cost of misjudging the first update is higher than ever: you can lose the users you just started gathering, all at once. Today I want to write down the three priorities I always honor when shaping the first update after a launch, drawn from twelve years of running apps.
Priority 1: Fix the crashes that no review ever mentions
The first thing I look at is never the reviews. It is always Crashlytics.
This sounds counterintuitive at first, but the crashes that actually break an app rarely make it into the reviews. Users do not write before they uninstall. If you are lucky, you get a one-line review that says "didn't work, deleted." Most of the time, what you get is silent churn that simply does not show up anywhere except in the analytics. Beautiful HD Wallpapers, one of the wallpaper apps I run, went through a period where RecyclerView threw an IndexOutOfBoundsException on a specific code path. The reviews said only "slow" or "images don't load." Crashlytics, on the other hand, showed the same crash hitting more than fifty users over twenty-eight days.
The fix for this is not a new feature. It is defensive code. Whether your app was built with Rork or written natively, the paths that run at launch and the paths that only first-time users touch are where post-launch bugs hide. I have decided that the first update should clear out the issues that never appear in reviews but that push crash-free users below 99.5%. It is not glamorous, but it is the most direct way to stop silent churn.
In practice, I walk through this checklist within the first day or two:
[Crashlytics check right after release]
1. Has crash-free users dropped below 99.7%?
2. Has ANR climbed above 0.20%?
3. Has the same stack trace appeared three or more times in 24h?
4. Is the issue concentrated on a single old device (Android 6.0, iOS 16, etc.)?
5. Are the crashes clustered within five seconds of launch?If any single item triggers, the first update becomes a crash-fix release and nothing else. The feature requests can wait until the next one. Nobody notices their absence; everyone notices the crash.
Priority 2: Fix the visible damage before the invisible improvements
After crashes come the broken behaviors and visible glitches. This is where a clear filter becomes necessary.
Every freshly released app has a few corners that are obviously broken from the user's side: a button that does nothing, a screen that hangs halfway through, an image that never appears. The faster you build with Rork, the easier it is to skip a corner case here and there. I trip on this myself.
When I am choosing between visible damage and invisible improvement, I always ship the visible fix first. The reason is simple. A user's trust in an app is mostly decided in the first seven days. A memory of "it didn't work when I opened it" is hard to overwrite later, no matter how clean the internal refactor that followed.
For example, when Ukiyo-e Wallpapers shipped its multilingual update, there was one language in which the share button silently failed. No review mentioned it, but retention for users from that region was visibly weaker than the others. I had been planning to bundle the share fix with an internal loading optimization in a single update. In the end I shipped only the share fix first, and pushed the optimization to the release after. The first update needed to be small and obviously about restoring confidence.
The principle I keep coming back to: a "first impression fix" and an "important internal improvement" should not share a release. If a new bug slips in, mixing the two makes it almost impossible to isolate the cause. The first update should be small and almost boring: it should only address what users can already see.
Priority 3: Treat the review requests as data, not a roadmap
The third priority is the hardest one to hold to: the feature requests in the reviews.
Right after launch, reviews can contain almost anything. "Add a favorites feature." "Please add dark mode." "Too many ads." "I want a free version." On the surface, addressing each of these in order seems like the way to make users happy. After twelve years of doing this, what I have learned is the opposite. Half of the requests written in the first few days are forgotten by the people who wrote them within three weeks.
The early days are when users have not yet settled into how they actually use the app. The feedback they leave during this period is more likely to be a passing thought or a generic comparison to other apps, rather than something that reflects how they would really use yours later. So even if I do address a request in the first update, I always run it through this filter first:
[Filter for feature requests in the first update]
1. Is this request coming from multiple, independent users within one week?
2. Does adding it preserve, rather than dilute, the existing simplicity?
3. Will the version of me looking back in three weeks still think it was worth it?
4. Is it compatible with the existing AdMob and monetization design?
5. Can it be shipped without endangering the stability of what is already working?If two or more answers are "no," the request waits. I will often reply to the review with a short note saying it is on the list for a later update. Just being acknowledged tends to be enough. With Beautiful HD Wallpapers in its early days, I tried to implement every request that landed in reviews. The app swelled, the original wallpaper experience got diluted, and the rating actually fell. Since then I have come to feel that polishing one feature beats adding several, and that the rating tends to follow.
With Rork, the design of the first update reveals everything
Apps built with Rork ship faster, which means the first update carries more weight in shaping the direction of the project. The order in which you fix things, not the speed at which you build them, is what makes an indie operation visible to the outside world.
I grew up around two grandfathers who were temple carpenters, and one of the things I absorbed from them, almost without noticing, was that fixing something carefully with your hands is its own kind of devotion. I think about the first update of an app in the same way. Patch what is broken before adding something new. Restore the visible parts before optimizing the invisible ones. Listen to user voices slowly rather than reacting in the first 48 hours. Holding to that order, I have come to believe, is what makes it possible to still love an app five years later. That is the feeling I am left with after running apps to a cumulative 50 million downloads.
In the pre-Rork era, there was more time to take things slowly after release. Store reviews moved at a different pace, and user growth was gentler. In the Rork era, the verdict on a release tends to form within 72 hours. That is exactly why the question of what to put in the first update is worth thinking about before you press the speed pedal on Rork itself.
If you want to think about post-launch operations more systematically, I would also recommend reading How I Earn the First 100 Downloads for a Rork App and When You Have Too Many Ideas in Rork: A 12-Year Indie Developer's Filter for Choosing What to Build. Together with this article, they give a fuller picture of how I currently think about operating an indie app business.
Quietly, but carefully, fix what matters
The first 72 hours after launch are the easiest time to be pulled around by review counts and star ratings. Even now, I still have moments of opening reviews late at night and feeling my emotions move. But when the Crashlytics dashboard and the wishlist in the reviews sit side by side, I keep choosing Crashlytics. Stopping the silent churn matters more, in the long run, than answering the loudest voices. That has been my honest takeaway after twelve years.
Releasing an app to the world is more accessible than ever with Rork. That is exactly why how you maintain it afterward is becoming the real differentiator in indie development. The contents of the first update are, in a quiet way, a declaration of how you intend to live with this app from here on. I hope this helps a little if you are also somewhere in those wobbly first days after a launch.