Most apps are deleted within 72 hours. That number gets quoted at every product talk for good reason — it’s the rare metric that’s both depressing and actionable. Depressing because the median app you ship will be gone by the weekend. Actionable because the survivors all do a small number of things deliberately.
After shipping a few dozen mobile products, we’ve found that the apps people keep share three behaviours. They’re obvious in retrospect. They’re hard to actually do.
1. Solve one real job
The fastest way to get deleted is to be a worse version of a website. If the user can do the same thing in the browser without giving up screen real estate, they’ll delete the app the moment the storage warning fires.
Apps survive when they do something a browser can’t do as well: offline-first capture, push notifications a user actually opted into, hardware integration (camera, biometrics, NFC), or just the muscle memory of opening one icon instead of typing a URL. Pick the one or two of those that’s actually true for your product, and design the home screen around them.
2. Respect users’ time
The most underrated mobile metric is the time from tap icon to got value. We aim for under three seconds. That budget shapes a lot of architectural choices:
- Cold start < 1s. Lazy-load anything not on the first screen.
- No splash screens that are actually loading screens. Your splash is a brand moment, not a place to hide a 4-second API call.
- Show stale data, then refresh.Don’t leave the user staring at a spinner when you could show last week’s feed in 50ms and quietly hydrate.
- Skeleton screens, not spinners.A skeleton tells the user what they’re about to see; a spinner tells them to wait.
3. Earn the second open
Onboarding is your only chance to teach what the app does, but most teams use it to teach what the app is. Wrong instinct — nobody cares what your app is on day one; they care whether tapping it again tomorrow makes their life better.
The onboardings that work tend to share a shape:
- Reach an “aha” moment in 60 seconds. Whatever the smallest version of value is, get the user to it before asking them for anything.
- Defer signup as long as possible. If the user can try the product first, they will. Then the signup feels earned.
- Notifications opt-in after value is delivered. Asking for push perms on screen 1 is the surest way to never send a push notification.
Choices that pay back compound interest
Some technical decisions look invisible to users but quietly buy you months of velocity later:
- Offline-first data layer. Treat the network as an optimisation, not a precondition. The app feels faster, ships fewer bug reports, and works on the subway.
- Feature flags from day one. Ship dark, roll out gradually, kill fast. The cost of building this is one afternoon; the cost of not having it is one bad release.
- Crash & perf monitoring before launch.If you don’t have Sentry/Crashlytics and traces wired up before TestFlight, you’re flying blind in production.
- Accessibility from the start.Dynamic type, sufficient contrast, screen-reader labels — cheap to add up front, expensive to retrofit, and required in more jurisdictions every year.
How we approach this
When we design and launch an MVP on mobile, the first version is intentionally smaller than the team’s instinct. One job, done well. Telemetry baked in from day one. Onboarding pressure-tested against the “under 60 seconds to aha” rule. Everything else — settings, edge cases, that fourth tab someone insisted on — lands in v0.2.
Takeaways
- Be a better version of something the browser can’t do.
- Optimise for time-to-value, not time-in-app.
- Earn the second open before you ask for the email or the push perm.
- Ship telemetry, flags and a11y on day one — not version 2.
