Android apps people keep using after launch day.

We publish and run our own apps, so we know what happens after launch day. That is a different discipline from building an app and handing it over.

A phone held in one hand, with a finger reaching for the screen

What we measure

  • Installs (not what we judge you on)
  • Crash rate (not what we judge you on)
  • Who comes back

20%of users come back · our VPN app

Most app projects are priced as if launch is the finish line. In practice, launch is where you find out what you actually built.

  • The buildDone
  • Launch dayShipped
  • What did you actually build?Unknown

Our own apps

Our own VPN app, rebuilt around why people really left.

Zip VPN is ours. The numbers below are what it does, and the measurement behind them is the same work we would do on yours.

people using it each daydaily users
20,000
events recorded a day
300,000
of users come back
20%
Read the full case study
Zip VPN connected to Amsterdam, with a running timer and live transfer figures

When a location does not answer

BeforeAn error

AfterThe next location, by itself

What changes

What you can answer after launch.

Measured from the first release, not the third.

  • You can say

    Where a first session ends

    The screen people close the app on, on the specific devices it happens on. It is rarely the screen anyone guesses.

  • You can say

    Who comes back

    And what those people did on day one that the people who left did not. That difference is the whole product roadmap.

  • You can say

    What a crash actually costs

    Not the crash rate. The number of users who never opened it again afterwards.

A phone with a blank green screen held in an open hand at a desk
Tested in the handA build is finished when it has run on a real phone in somebody's hand, on the network they actually have. Our own apps go through exactly this first, which is much of the case for hiring a studio that publishes its own.

What is included

Everything from the first build to your Play Store listing.

  • Native Android in Kotlin, or a cross-platform build where that genuinely suits the product better
  • Play Console setup: listing, Data safety form, content rating, staged rollout
  • Crash reporting and event measurement in the first release, not the third
  • A privacy policy and account deletion route that satisfy Play policy rather than gesture at it
  • Store assets: icon, feature graphic, screenshots that show the app doing something
  • A release process written down, so a version can ship without us

The tools

Tools any Android developer will recognise.

Named once, for the person checking the work.

  • Kotlin and Jetpack Compose
  • Firebase: Analytics, Crashlytics, Remote Config
  • Google Play Console, with staged rollouts
  • BigQuery, where event volume justifies it
  • GitHub Actions for builds

FAQ

The questions we hear most.

Android is where we publish and run our own apps, so it is where our experience runs deepest. If your project needs an iPhone app too, we will say plainly whether we are the right team for it, rather than learn on your budget.

Your turn

Bring the app, or the idea, and one question about it.

Tell us about it in a few minutes. Within a working day we will come back with the smallest version worth shipping, roughly what it would take, and whether we are the right people for it.