What we learned building an automated app store optimisation platform

How an app gets found depends partly on the words and pictures on its store page. Yet plenty of independent developers and small studios had no real process for improving them. Serious tools existed for big publishers. Everyone else was working off the occasional spreadsheet and a hunch.

The job is also wider than it first looks. Doing it properly meant repeating six separate pieces of work, in every country that mattered:

TapTimize tried to squash all of that into one workflow. The pitch was never that an algorithm understood your app better than you did. It was that software could gather and organise enough evidence for a small team to make a decent decision every week instead of once a year.

What people saw was an Angular dashboard. The difficult part sat behind it. Store pages and search results had to be collected from country after country, turned into consistent records, and revisited often enough to build a ranking history worth reading.

Underneath was a Node.js API, MongoDB, RabbitMQ and a set of Python services doing the analysis, with Kubernetes and Terraform describing production and CI/CD making frequent changes less frightening. That sounds like a lot for an early-stage product, and it was. But the work genuinely was a pile of independent jobs, each of which could be slow or fail for reasons that had nothing to do with our code.

The queue made that boundary honest. The API did not have to sit and wait while every keyword in every market was checked. Workers could retry, scale on their own and save partial progress. If you are collecting data from someone else’s service, model it as jobs from day one. Retrofitting that later is miserable.

A position on a given day is just an observation. It becomes evidence when you can attach it to a country, a language, a device, a store, the competitors around it, the version of the listing that was live and the date you last changed something. Without that, a chart mostly encourages stories the data cannot support.

So the product needed history rather than snapshots. Did the movement hold? Did related terms move together? Did a change help in one country and do nothing in another?

And ranking was never the actual goal. Better visibility gets more people onto the page; the icon, the screenshots, the reviews and whether the app is any good decide what happens next. Apple and Google both make that split clearer now with product page tests and store listing experiments. Getting found and getting installed are connected, but they are separate problems.

Finding more keywords, comparing competitors, collecting rankings and checking that a title fits the character limit are all good candidates for automation. They are repetitive, well defined and get better when the same method is applied consistently.

Writing the whole listing without anyone reading it is a different matter. A model can combine your vocabulary with what people search for, but it does not know which claims are true, which benefit matters most to your customer, or which phrase sounds natural in Brazil. The version that works generates options and shows the evidence for each, then lets a person decide.

That boundary also keeps you honest. Repeating a popular phrase does nothing if the app does not do the thing people were searching for. A store listing has two audiences, the search system and the human deciding whether to install, and misleading either one stops working quickly.

People search differently in different places. Two countries can describe the same task in completely different words even when your translation is perfect. How crowded a term is and how many people search for it change too, so something hopeless in one market can be an easy win in another.

TapTimize treated each language as its own optimisation problem. That meant more data to collect and more text to manage, but it stopped one English keyword list being dressed up as a global answer.

The same thing is true in today’s tools. Apple lets you localise product pages and point custom ones at specific content and keywords; Google Play supports localised listings and experiments. The mechanics have moved on, but the useful habit has not: pair somebody who knows the language with numbers from that market.

We started charging during the beta. The 2018 thesis that documents the product records monthly income going from roughly $500 to $3,246 by the end of May. Small, first-party, unaudited numbers, but enough to show the problem was worth paying to solve.

Paying customers ask completely different questions from interested testers. How fresh is this data? Why is my market missing? Why should I trust this recommendation? Does this save me enough time to justify the bill? That pressure is what turned a clever algorithm into something resembling a business.

I am not naming customers here. The transferable part is the habit: measure what happened, say where the number came from, and never present one good result as though it were a forecast.

TapTimize later moved away from app stores towards a simpler web keyword tracker, and eventually shut down. A retrospective should just say that. Software can solve a real problem, find people willing to pay for it, and still not become the company its founders wanted or a market that could support it.

What lasted was the full loop: take a vague marketing practice, turn it into jobs a machine can do, build the thing that collects and analyses the data, charge for it, listen to the people paying, and change direction when the original shape stops making sense.

If you are building anything data-heavy today, that is the part worth stealing. Dashboards can be redesigned. Working out what evidence your customer actually needs, collecting it reliably and being honest about where the automation stops is the harder skill.