Building Strong for the Future of ASO
What it actually takes to build a production-grade ASO platform — and why a ChatGPT wrapper will never get you there.
Thomas Purnell-Fisher / TL;DR
Apptonomy is a deeply engineered platform designed by ASO experts that sources app intelligence from many providers then runs a battery of 100+ hierarchically stacked AI prompts to assemble a comprehensive assessment of a given app’s store listing strength and specific recommendations for further optimization.
The platform generates new assets, localizes in 88 languages, provides deep analytics with App Store Connect and Google Play Console integrations — and supports one-click publishing of revised app listings to the stores.
Vibe-coders can’t get anywhere near the depth of this platform, building it in-house requires both extensive ASO expertise and months of world-class engineering, and the incumbents are too slow and too vision-challenged to build this.
Who Am I?
I’m Co-Founder and CEO of Apptonomy. My day-to-day focus is on product development: user experience design & engineering.
I’ve been coding and building for the web since the mid-90s. I spent time as a Product Director at Google and Netflix where I was the first product leader working exclusively on streaming. I’ve led projects involving hundreds of people and my own teams have been up to around a hundred people across engineering, product management, design, and data science.
A few things I’ve built over the years:
- Phoenix — DVD emulator & post-production tooling used by every major studio in Hollywood.
- Render Monster — 3D rendering platform on AWS EC2, in 2008, when that was quite extraordinary.
- Veezy — The first iOS app to support live broadcasting from a phone over a mobile network.
- Quanta — An iOS app that helped people live more profitably by tracking exactly how much they earned and spent every day.
- Taalia — An early AI-powered language instruction app for iOS and Android.
I’m also co-inventor on four patents.
All that to say, I’ve been developing products and running teams for a long time — I know what good looks like when it comes to user experience and deep product engineering.
Why We Built This
ASO is accelerating — the rate of change in the behavior of the App Store and Google Play is rendering existing ASO practices and tooling ineffective. The rise of app discovery via LLMs changes the ASO game further. Add to that the speed with which app publishers can develop and launch new apps thanks to the latest AI models and you have a situation where there’s growing demand for ASO automation and legacy tools are growing less effective.
Against that backdrop I’d built and launched a prototype app listing localization platform called Apgio and was chatting with ASO professionals about it. That’s how I met Yevhen Tarasenko with whom I had some interesting discussions about the direction of the ASO industry. Fast forward a couple months and he publishes a dead-on-subject blog post How to Automate 40% of Your ASO Workflow. I messaged and asked him two questions: (1) shall we build it? (2) can we make it 80%?
He said yes to both. So we co-founded Apptonomy and set out to design and build the first version of the platform.
By bringing together Yevhen’s ASO expertise and my product engineering, our aim is to operate the industry-defining ASO platform for this new era of mobile app marketing.
Unvibecodable
There’s a pattern in the current wave of AI-powered tools: take an API, wrap it in a Next.js app, deploy to Vercel, call it a platform. Ship fast, raise money, figure out the engineering later.
Apptonomy is the opposite of that. It wouldn’t exist without LLMs — especially the models that have landed in the past six months — but the AI is embedded within a deep tech stack built on real system architecture, real security, and real UX design. The AI does what AI is good at. The engineering does everything else.
Here’s what I mean concretely:
-
The ASO expertise is human, not prompted. Throughout the platform, the decisions about what to analyze, how to score it, and what constitutes a good recommendation come from Yevhen’s years of hands-on ASO work with real app publishers. We’re not asking ChatGPT “what makes a good app store listing?” We already know. The AI executes against our expertise — it doesn’t replace it.
-
The orchestration is massive. A single audit hits a couple dozen external data sources, then runs a battery of over a hundred intertwined AI prompts across six different models. Each engine has its own caching, cost tracking, and failure handling. Try orchestrating that on a vibecoded platform while also making it scale in speed and cost for users around the world and in 80+ languages.
-
Localization is its own engineering domain. It’s easy to ask AI to translate some text. ASO demands awareness of the app’s capabilities, brand, tone-of-voice, marketing posture — and per-field character limits that differ by store and language. This part of Apptonomy was actually inherited from my previous product, Apgio, which we’ve folded in. It’s been refined for over a year and used in production by many app publishers.
Under the Hood: Six Models, Dozens of Data Sources
When I say Apptonomy uses AI, I don’t mean we send your app description to one model and return whatever it says. That’s what the wrappers do.
Apptonomy runs six different AI models from OpenAI, Google, Anthropic, and Perplexity — each selected for specific tasks based on what it’s actually good at. Some models are better at structured analysis. Some are better at creative generation. Some are better at image analysis and generation. Some are faster and cheaper for routine work. We route to the right model for each job, and every call returns structured, schema-validated data — not prose we have to parse with regex.
But the AI is only as good as what you feed it. That’s why the platform integrates with over a dozen external data sources, each with its own authentication, rate limits, and failure characteristics:
| Source | What It Provides |
|---|---|
| Apple App Store | Official Apple data, analytics, publishing |
| App Store Connect | Official Apple data, analytics, publishing |
| Apple Search Ads | Keyword popularity, impression share |
| iTunes API | Public Apple metadata |
| Google Play Store | Official Google data, analytics, publishing |
| Google Play Console | Official Google data, analytics, publishing |
| Google Ads | Search volume, keyword difficulty |
| Google Trends | Trend direction scoring |
| Cloud Vision | Text detection in screenshots |
| Brand exposure and sentiment | |
| Others… | Additional app intelligence |
Each of these services has its own quirks. The iTunes API is “free” but has undocumented rate limits that change without notice. Google Ads enforces 3 requests per second globally. Some of the most valuable intelligence sources weren’t designed to be queried programmatically at scale — gathering that data reliably, across thousands of apps and dozens of markets, requires its own infrastructure layer. Managing all of this — with proper error handling, retry logic, request distribution, and graceful degradation when a source is unavailable — is a substantial engineering challenge that doesn’t show up in a feature comparison checklist.
Every API call and model invocation gets cost-tracked. Per-engine, per-model, per-provider. That data feeds back into our model selection — if we can get equivalent quality from a cheaper model for a given task, the numbers tell us.
Two Runtimes, One Platform
The most fundamental architecture decision was splitting the platform across two runtimes. This wasn’t complexity for its own sake — it was a direct response to conflicting requirements.
The API layer runs on Cloudflare Workers at the edge — near-zero cold starts, global distribution, responses served from the nearest point of presence. When you interact with Apptonomy, the UI feels instant because the API is running on infrastructure designed for speed.
But the ASO engines need things edge runtimes can’t provide: long execution times (some engine runs take 30+ seconds), access to the full Node.js ecosystem, and direct integration with our data layer. So the compute-heavy work runs on GCP Cloud Functions — full Node.js, event-driven, designed for the heavy lifting.
┌───────────────────────────┐
│ Apptonomy Web App │
└─────────────┬─────────────┘
│
┌────────────▼────────────┐
│ API Layer (Workers) │
│ Global · Fast · Auth │
└──┬─────────┬─────────┬──┘
│ │ │
┌───────▼──┐ ┌───▼───┐ │
│ R2 (CDN) │ │ KV │ │
└──────────┘ └───────┘ │
│
┌─────────────────────▼───┐
│ Compute Layer (GCP) │
│ Engines · AI · Heavy │
└──┬──────────────────┬───┘
│ │
┌──────▼─────┐ ┌──────▼──────┐
│ Firestore │ │ BigQuery │
└─────────────┘ └─────────────┘The split is clean: Workers handle routing, auth, and fast responses. Cloud Functions handle computation, external integrations, and data processing. Four storage systems underneath, each chosen for its specific access pattern — real-time operational data in Firestore, analytics time-series in BigQuery, CDN assets in R2 with zero egress fees, and edge configuration in KV.
Store Credentials: Secured Like They Should Be
If you’re going to connect your App Store Connect or Google Play Console account to a platform, you need to know your credentials are safe. This was non-negotiable for us.
When you upload a .p8 private key or a service account JSON to Apptonomy, it’s encrypted in your browser before it ever hits our servers. AES-256-GCM encryption with a key that’s wrapped using our RSA public key — we can’t read your credentials in transit even if we wanted to.
On the server side, the wrapped key is unwrapped by Google Cloud KMS — a hardware-backed key management service where the private keys live in Google’s infrastructure, not in our code. Your credential is then re-encrypted with a key derived specifically for your account using HKDF with a per-user salt. That encrypted credential is what gets stored.
When we need to make an API call to App Store Connect or Google Play on your behalf, your credential is decrypted in memory, used to generate a short-lived token (10 minutes for Apple, 60 for Google), and immediately discarded. No plaintext credentials are ever persisted, cached, or logged.
This is the kind of security architecture you’d expect from a fintech platform, not an ASO tool. But if we’re asking publishers to trust us with their store access, this is the standard we should be held to.
This Is Just the Beginning
We’ve launched a v1 and it is already delivering for our early users. We’re incredibly proud of this thing but we know there’s a lot of work ahead of us. From here we listen to our users and continue executing on our vision for the coming months and years as we refine and extend the capabilities of Apptonomy to help our customers expand their mobile app businesses.
Run the Audit
Don’t take my word for it — run a free audit on your app and see what comes back. The depth speaks for itself.
AI Disclosure: This post is an original work, hand-written by Thomas. AI was used only after a full first draft was done — it provided some structural advice but the composition is entirely his own.