About

I read reviews for a living. That's the whole business.

TrackGap is one person with a classification pipeline and a lot of patience. There is no company behind it, no investors, and no product team. That is deliberate — it's also the reason this exists at all.

What actually happens

Every app I look at gets the same treatment. I pull its public customer-review feed, take the most recent batch of written reviews, and read every 1–2 star one. Not a sample of them — all of them. Each goes into a fixed taxonomy: stability, missing features, pricing, subscription and billing, support responsiveness, performance, competitive loss.

Then I read the output by hand and throw away whatever doesn't hold up. The coverage number on every result tells you how much got classified cleanly; the rest is excluded rather than guessed at.

It takes about fifteen minutes per app. Most of that is reading, not running code.

Why it exists

The tools in this space are built for teams managing their own reviews at volume. They are good at that. But they show you your dashboard — they don't tell you what your competitors' users are complaining about, using the same method, in the same week, side by side.

That gap is the entire product. Not "review management." The sentence a product lead actually wants and can't easily get:

"Your top complaint is billing after cancellation. Your competitor's is crashes, and their rate is nearly double yours. Here's the specific thing your users keep asking for that theirs already have."

That is a different question from "how are my reviews doing," and it needs different data.

What it costs

The first one is free. If you work on a field-service app, send it over and I'll run the classification and send back the breakdown — counts, categories, and how you compare against three named competitors. No account, no signup, no card.

If it's useful, there's a paid version with more depth. If it isn't, you've lost fifteen minutes of reading and I've lost fifteen minutes of work. That's a fine trade for both of us.

What I won't do

Hard limits

  • Publish review text, usernames, or avatars — ever
  • Use private data, logins, or App Store Connect access
  • Tell one client what another client's data shows
  • Name a client's weak spots to their competitor
  • Pretend a small sample is a large one

What you get

  • Counts and recurring functional phrases, attributed to no one
  • The coverage number, so you know how much we missed
  • Sample sizes stated plainly, including when they're thin
  • A correction if I got something wrong — just tell me
  • Straight "your data doesn't support a conclusion here"
The legal line, stated plainly. Everything here comes from Apple's public customer-review feed. I publish counts and recurring functional phrases — never the review text itself. A count is a fact about a public dataset; someone's written review is their words, and those stay where they are. This is also the line that makes the business sustainable rather than a lawsuit waiting to happen, so it isn't a marketing position — it's how the pipeline is built.

Who this is for

Product managers, heads of product, and founders at field-service software companies — the people who own the mobile experience and get judged on it. If you're a technician, a customer, or an investor, this probably isn't useful to you.

I'm not affiliated with any of the apps I analyse, and I'm not endorsed by any of them. Names are trademarks of their owners, used to identify what's being discussed.

Send me an app.

Free, and you'll get the breakdown whether or not we ever talk again. Start with the category research if you want to see the method first.

t888st@outlook.com

Email the app name (or a store link) and you'll get the breakdown back — usually within a week.

Read the research →