Skip to content

Writing

Building developer tooling for mobile: what 100,000 installs taught us

4 min read

We published a reference app for Termux — the terminal environment on Android — covering the commands and what they actually do. It passed 100,000 installs and holds 4.8 from more than 400 reviews on Google Play.

It is also not being developed further, and the reasoning behind that decision is more useful than the build was.

Power-user audiences are small, loyal and unforgiving

A tool for developers has a different shape from a consumer app in three ways that matter.

  1. Discovery is almost entirely word of mouth

    Nobody browses an app store for a terminal reference. They arrive from a forum thread, a Reddit comment, a search for a specific command. Store optimisation moved the number far less than being genuinely the best answer to one question.

  2. The bar for correctness is absolute

    A consumer app with a wrong label gets a shrug. A reference with a wrong flag gets a one-star review explaining precisely why, and that reviewer is right.

  3. They will tell you exactly what is wrong

    Which is the compensation. Developer reviews are the highest-signal feedback we have ever received on anything — specific, reproducible and technically literate.

What we would do differently

  1. Offline-first from the first commit, not as a later fix

    A terminal reference is used in exactly the situations where connectivity is poor. Every lookup must work with the radio off, which means the content ships with the app rather than being fetched.

  2. Search before browse

    Our first structure was categories. People arrive knowing the word they want — they type tar, not "archiving utilities". Search should be the home screen for a reference tool.

  3. Copy is the primary action

    Every command needs a one-tap copy. On a phone, retyping a command with flags is the whole reason somebody opened a reference in the first place.

  4. Version the content against the tool

    Flags change. A reference that does not say which version it describes will eventually be confidently wrong, and confidently wrong is worse than absent.

The retention number, and reading it honestly

The interesting metric was not installs. Over one 28-day window: roughly 101 new users against 188 lost, with 563 active devices against 141,000 lifetime installs, and one crash.

The first instinct is that this is a quality problem. It is not — one crash across that base is a stability record most apps do not have.

That reading is what made the decision straightforward. It was not a discovery problem — 141,000 people found it. It was not a stability problem — one crash. It was that the thing it was best at, being the clearest first answer, is now served better by other sources.

Deciding to stop is a product decision, not a failure

The honest options were to invest properly — rewrite the content against current versions, rebuild search, ship offline-first — or to leave it published and say plainly that it is not being developed.

We chose the second, and stated it in the listing rather than letting it rot silently. A tool that quietly stops being updated while still claiming to be current is worse for its users than one that says where it stands.

  1. Leave it up if it still works

    563 people use it. Removing it helps nobody.

  2. Say it is not being developed, in the listing

    So somebody choosing a reference can factor that in.

  3. Do not fold its numbers into anything else

    Installs are not downloads, an install is not an active user, and a 141,000 figure sitting next to unrelated metrics implies a scale that is not there.

What transferred

The app is finished; the lessons were not.

  1. Offline-first is an architecture, not a feature

    We now build sync, outboxes and local-first storage the same way for field operations software, where the phone leaves coverage mid-task.

  2. Search-first beats hierarchy for reference material

    It shaped how we build documentation and content indexes since.

  3. Publishing something to a large audience changes how you write

    A wrong flag in front of 100,000 people is a different kind of pressure from a wrong flag in an internal tool, and it raised the standard for everything published afterwards.

Start here

Tell us what you are building

Or what is breaking, or what has to go faster. You will get a straight answer from an engineer who would do the work.