Before You Launch: The Competitive Research Every Indie Developer Should Do

Most indie iOS apps do their competitive research after launch, when downloads come in flat and someone finally opens SensorTower to find out why. By then the expensive part is already locked in. Your title, subtitle, and keyword field can only change with a new version submission, and the positioning baked into your screenshots and description took weeks to produce.

Pre-launch competitive research is the cheapest work you will ever do on an app. It costs an afternoon and it changes decisions that would otherwise cost months. This is the checklist: seven questions, in order, with the specific data that answers each one and the decision that follows from it.

The examples throughout use App Store Operator to pull the numbers, because getting download estimates, revenue estimates, ratings, publisher data, and top markets for a keyword takes one query rather than an hour of tab-switching. But the checklist is the point. Run it with whatever data source you have.

---

Why Pre-Launch, Specifically

Three things become expensive the moment you submit.

Your metadata is version-locked. The App Store title, subtitle, and keyword field can only be changed by submitting a new version. Not a config toggle, not a dashboard edit — a build, a review, a release. If you pick your primary keyword badly, correcting it costs a release cycle, and you lose whatever ranking history the old terms accumulated.

Your positioning is baked into assets. Screenshots, preview video, and description are written around a specific claim about who the app is for. Discovering after launch that the audience you targeted is already well served by an incumbent — and the underserved audience is a different one — means redoing the whole asset set.

Your launch velocity only happens once. The first two weeks after release generate a download and rating spike that the App Store algorithm reads as signal. Spending that spike on a keyword you cannot rank for wastes the one moment when ranking movement is cheapest.

None of this is fixed by working harder after launch. It is fixed by ninety minutes of research before it.

---

Question 1: Who Actually Ranks for Your Keyword?

Not who you think your competitors are. Who occupies the search results for the term you intend to put in your title.

These are different lists more often than developers expect. The apps you have been benchmarking against on feature parity are frequently not the apps that own your search term. A well-optimised, mediocre app can sit above a better product it has never been compared to.

Start with the raw ranking:

Search the US App Store for "[your primary keyword]" and give me the top 10 apps with their IDs.

Write the list down. This is your actual competitive set for that term, and you will use the app IDs again in question 4.

The decision this drives: whether your keyword assumption survives contact with the search results at all. If the top ten for your term are serving a different use case than yours, your term is wrong, and you have found that out before writing a screenshot.

---

Question 2: What Is the Download Ceiling in This Niche?

The single most useful number in pre-launch research is the estimated monthly download count of the top-ranked app for your keyword. It sets the ceiling on what winning looks like.

Research the top rivals for "[your primary keyword]" in the US App Store.

That returns download and revenue estimates for the top-ranked apps. Read the top number as a ceiling, then discount it hard for yourself. Position one is what a category leader with years of accumulated ratings gets. What you should model is position three to five in the first year.

Rough interpretation of the leader's monthly downloads:

• Under ~1,000/month: the keyword is too quiet to build a launch on. It might work as a supporting term in your keyword field, but it cannot be your title.
• ~1,000 to ~10,000/month: the sweet spot for a new indie app. Real traffic, usually a fragmented middle, and positions three to five are genuinely reachable.
• Over ~50,000/month: high traffic, and almost certainly a locked top five. Treat it as an aspiration, not a launch plan, and go find a mid-tail variation.

The decision this drives: whether your growth model is even arithmetically possible. If you need 2,000 installs a month to hit your revenue target and the category leader gets 900, no amount of ASO fixes that. You are in the wrong niche, and it is far better to learn that before you build.

---

Question 3: Does This Category Actually Monetise?

Downloads and revenue are not correlated as tightly as people assume. Plenty of categories generate substantial install volume and almost no money, because users in that category have been trained by a decade of free apps to expect free apps.

The ratio to look at is estimated monthly revenue against estimated monthly downloads for each top app. You do not need precision here; you need the order of magnitude.

• A leader doing 9,000 monthly downloads and $110,000 monthly revenue tells you this audience pays, and pays on subscription.
• A leader doing 40,000 monthly downloads and $3,000 monthly revenue tells you this is an ad-supported or free-forever category. A subscription app entering it will convert badly no matter how good it is.

Check the ratio across the top three, not just position one. A single well-monetised leader in an otherwise free category usually means that app has a brand, not that the category pays.

The decision this drives: your monetisation model, and whether the app is worth building as a business at all. This is the question that most often kills a project early, which is exactly what you want it to do.

---

Question 4: Who Are the Publishers, and Are They Defending?

Publisher data is the most underused field in competitive research. It tells you whether the app above you is a company with a dedicated ASO function or one person who shipped it three years ago and moved on.

For each app in the top five, you want three signals: publisher name, publisher country, and last updated date. An app that has not been updated in eighteen months is not being defended. An individual developer in a market unrelated to yours is unlikely to respond when you start taking their ranking. A funded company with monthly releases will.

If you have specific app IDs from question 1 that you want examined directly:

Get details for these app IDs: [ID], [ID], [ID] — US store.

Read the result as a map of where the pressure comes from. A top five made up of one strong company and four dormant individual publishers is a very different launch than five active companies.

The decision this drives: which position you are actually targeting. You do not plan to beat the leader in year one. You plan to displace the specific weak app sitting at position four, and now you know which one it is and whether anyone will push back.

---

Question 5: Which Markets Are the Incumbents Actually Winning?

A keyword can look crowded and be wide open for your audience.

The top markets field shows which countries drive the most downloads for each competitor. Apps regularly rank in the US store while drawing the bulk of their installs from Germany, India, Brazil, or Japan. They rank because their metadata is optimised, not because they are winning American users.

If two of the top five apps for your term have top markets that do not include your target country, the effective competition for your audience is three apps, not five. That is a materially different launch.

This is also where localisation opportunities surface. If the leaders are all English-first and your app supports Turkish, Portuguese, and Japanese, there may be a far easier ranking available in a store nobody in your competitive set is optimising for. Run the same query with a different country code and find out:

Now research the same keyword in the TR App Store.

The decision this drives: which country store you launch into first, and whether localisation belongs in v1 rather than v2.

---

Question 6: What Is the Rating Floor You Have to Beat?

Rating score and rating count together tell you how entrenched the top five are and where the soft spot is.

Rating count is a proxy for accumulated download history. An app with 200,000 ratings got there over years; that position is not available to you. An app with 400 ratings is either new or niche, and its position is contestable.

Rating score is the vulnerability signal. A top-five app sitting at 3.6 stars is telling you, in public, that its users want something better. That is the clearest entry signal in the entire dataset. The App Store algorithm rewards conversion and retention, and a well-reviewed new app grinds past a poorly-reviewed incumbent given time.

Note the lowest rating in the top five and treat it as your target. Then note the highest rating count and treat it as the wall you are not going through this year.

The decision this drives: your quality bar at launch, and how hard you push for reviews in the first month. If the weakest top-five app sits at 4.3, you need a genuinely excellent launch. If it sits at 3.5, a solid app with an honest review prompt gets there.

---

Question 7: Is There a Term You Can Own on Day One?

The first six questions evaluate the keyword you brought with you. This one finds the keyword you should actually launch with.

Take your head term and generate five to eight mid-tail and long-tail variations — the specific phrasings a motivated user types when they know what they want. For "expense tracker" that is "expense tracker for freelancers," "shared expense tracker," "business expense tracker," "receipt scanner expense." Then run questions 2 through 6 against each one.

Because results are cached for 24 hours, you can sweep the whole list in a single sitting and compare:

Research the top rivals for "shared expense tracker" in the US App Store.

Now do the same for "expense tracker for freelancers."

Compare those two against "business expense tracker" and rank them by how attainable a top-five position looks for a new app.

You are looking for one term where the leader gets meaningful volume, the middle of the top five is weak or dormant, the category monetises, and nobody is serving your specific angle. That term goes in your subtitle and structures your listing.

The decision this drives: your entire metadata strategy. The head term stays in your title where it reads naturally, but your ranking plan is built on the mid-tail term you can realistically own within a few months.

---

Turning the Checklist Into a Launch Decision

Run all seven and you land in one of three places.

Build as planned. Volume is real, the top five has a soft position, the category pays, and you found a mid-tail term nobody owns. Launch into it, put that term in your subtitle, and spend your first-two-weeks velocity on it.

Reposition. The category works but your angle is wrong — the audience you targeted is well served and a different one is not. This is the most common outcome, and catching it pre-launch is the entire return on the exercise. You change the positioning, the screenshots, and the primary keyword. You do not change the code.

Kill or pivot. No volume, or no monetisation, or a top five with no weak position and 100,000+ ratings apiece. Painful at week two of a project, considerably more painful at month eight. This outcome is the reason the checklist runs before the build, not after it.

---

The Mistakes That Show Up Most Often

Researching only the head term. The head term tells you the category is large. It does not tell you where you can win. The mid-tail sweep in question 7 is where the actual answer lives, and it is the step most often skipped.

Treating estimates as exact. Download and revenue estimates are modelled, not measured. Use them for order of magnitude and relative comparison — is this app 10x bigger than that one, does this category pay at all — and never for a spreadsheet that projects your own revenue to two decimal places.

Only looking at position one. Position one is not your competition in year one. Positions three through five are. Read the whole top five, and read the lowest-rated one most carefully.

Confusing feature competitors with search competitors. The app you compare yourself to in your pitch and the app occupying your keyword are often unrelated. Only one of them affects your downloads.

Doing it once. The pre-launch sweep is a baseline. Re-run the same queries a month after launch and the deltas tell you whether you are gaining, whether an incumbent has woken up, and whether a new entrant has appeared. Same queries, same keywords, thirty days apart.

---

Frequently Asked Questions

How long should pre-launch competitive research take?

For a single primary keyword and six to eight variations, roughly ninety minutes if the data pull is automated. The bottleneck is not analysis, it is retrieval — pulling downloads, revenue, ratings, publisher, and top markets for the top apps across eight keywords by hand is several hours of cross-referencing, which is why most developers skip it.

When in the project should I do it?

Twice. Once before you commit to building, when the answer to question 3 can still save you months. Once again two to three weeks before submission, when you are finalising the title, subtitle, and keyword field and need the current state of the top five.

What if my app has no direct competitors?

Then you have the wrong keyword, not a clear field. Every App Store search returns results, and those results are what your users will see alongside you. Search the term your user would actually type and analyse whatever ranks — those apps are your competition regardless of whether their feature set matches yours.

Can I do this without a paid ASO tool?

Yes. App Store Operator pulls download estimates, revenue estimates, ratings, publisher country, and top markets into Claude for free, with no subscription and no SensorTower plan. Setup is one command — see the setup guide for Claude Desktop and Claude Code.

How accurate are download estimates?

They are modelled from ranking and category signals rather than measured from Apple, so treat them as directional. They are reliable enough to tell a 1,000-download keyword from a 100,000-download keyword, which is the decision they need to support. They are not reliable enough to forecast your own revenue.

Should I research non-US stores before launch?

If you are launching worldwide, yes — at minimum your two or three largest expected markets. Competition varies enormously by country store, and question 5 frequently reveals that a keyword locked in the US is wide open in a market where you already have language coverage.

---

Run It Before You Submit

The seven questions in order: who ranks, what is the ceiling, does it pay, who is defending, which markets, what is the rating floor, and what term can you own. Each one has a decision attached, and every one of those decisions is cheaper to make before submission than after.

Set up the data pull:

claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest

Then start with question 1 on the keyword you were planning to put in your title:

Research the top rivals for "[your keyword]" in the US App Store.

The framework for reading the numbers that come back is in the competition analysis guide, and turning your shortlist into an actual metadata plan is covered in the App Store keyword research guide. If you want the fast version of the query workflow first, the 60-second competitor research guide is the shortest path to your first result.

npx app-store-operator@latest