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.
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.
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.
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
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.
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.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.
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.
Leave it up if it still works
563 people use it. Removing it helps nobody.
Say it is not being developed, in the listing
So somebody choosing a reference can factor that in.
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.
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.
Search-first beats hierarchy for reference material
It shaped how we build documentation and content indexes since.
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.