I was at a comunity meetup recently when someone told me he deliberately doesn't do competitor analysis. He didn't want it influencing his thinking, he said. He's vibe coding an iOS app. And that last detail is what makes his position genuinely interesting, because in most agency and enterprise settings, the decision to do or skip competitor work does not sit with the developer at all. It sits with the product owner, product manager or client, and the developer just executes what falls out of that decision. He is having the opinion because vibe coding his own app has collapsed the two roles into one person. He is a developer and product owner at the same time, and he has inherited the call the way most product owners in his position make it: skip it, and ship.
I have heard versions of the same view at WWDC, at NSLondon, at Londroid, at London Tech Week, at various startup events and in the startup alleys of larger tech shows, at a dozen conversations at meetups and side events across the last several years. It is a position I have been hearing for a decade, held by around 80% of the developers and product owners I've asked, and it turns up just as often among founders and solo builders who have never written a line of code themselves but are now shipping apps because the tooling has finally let them.
I say 80% because I have actually asked. Across WWDC 2018 and 2019 I ran informal surveys of the people I met in queues, over coffee, at side events. WWDC's attendees are a genuine mix: Apple platform developers, product owners and app owners, agency staff, founders shipping their own apps. I did not stratify by role at the time and I could not tell you the exact split of who I asked, only that it was a wide cross section of everyone the event actually attracts. The question was the same each time: do you or your team do competitor analysis on your own apps? Around 80% said no. Another 15% said "occasionally, when I remember." The remaining 5%, almost all larger teams and agencies working for enterprise clients, said they did something at major product cycles, once a year, or on request. That mixed sample matters, because the 80% figure is the overall answer across everyone I spoke to, not a developer-only number. The position was widespread across the room, not confined to one job title.
The practice they were opting out of is not obscure. It is standard business discipline, described in most reference works on strategy as the process of mapping the competitive landscape identifying and evaluating competitors' strengths, weaknesses and market positioning to inform your own. What is genuinely interesting about the mobile app development picture is not that the practice is unknown, it is that around 80% of the developers I spoke to had actively chosen not to do it.
This was not a scientific study. It was a working developer talking to other working developers, at scale, over two conferences. But the pattern held every time, and it has held every time I have asked since.
For a long time, the 80% were right.
The instinct is easy to caricature as purism or laziness. It was neither. In 2018 the calculation was straightforward.
Competitor analysis meant buying a Sensor Tower seat, which cost thousands of dollars a year and answered a narrow set of questions about downloads and revenue. It meant paying an agency for a market read, or running one yourself, which meant manual app market research App Store listings, review scraping, app feature comparisons, hours of work per app for information that was often out of date by the time you compiled it. For a developer working alone on their own app, the return-on-time was genuinely poor. Half a day spent on Sensor Tower reports was half a day not spent shipping features.
So the 80% did what any rational person does when the cost of information exceeds its likely value: they skipped it, and shipped instead. Some of them romanticised the choice afterwards as creative independence. Most just called it prioritisation.
There is a second version of this position, held by design and development agencies rather than individual developers, and it works on completely different logic. Agencies operate on scope. Scope is what the client asks for, and what the client agrees to pay for. If the client did not ask for competitor analysis, and most clients did not, it did not go in the brief. If it did not go in the brief, it did not get scoped or priced. So the agency delivered exactly what was agreed, for hell or high water, because once budget is agreed, scope creep is a bigger risk to the relationship than under-delivery. The client got the app they asked for. The agency delivered what they were paid to deliver. Neither party discovered what was missing from the brief until a submission bounced, a review team asked an unexpected question, or a competitor moved in a direction nobody had watched for. At which point it was somebody else's problem to explain.
I saw this happen repeatedly at Coderus, the UK app agency where the idea for Appnalysis was formed. A client would come in with a clear USP for the app, they knew what it should do, they had thought hard about the product. But ask them whether it was for mobile or tablet, which countries, which OS, and there was almost always a pause, and then some version of: you are the experts, what do you recommend? At which point recommending anything responsibly meant actually doing the research. And doing the research meant time, which meant cost, which meant a difficult conversation about a bigger brief than the one the client thought they were signing. The devil was very much in the details, and both sides felt it every time. That pattern, repeated across enough client engagements, is a large part of why Appnalysis exists at all: the alternative to having that conversation every time is having the answers already, at the level of specificity a real client brief actually needs. Our story goes into more of that history if you are curious about how we ended up building this.
Both versions of not looking, the developer's version and the agency's version, arrived at the same outcome: an app shipped without competitive or market intelligence. But the mechanisms were completely different. The developer chose. The agency was structured out of the choice.
The instinct to design at distance from competitors has a formal name. In competitive intelligence practice, it is called clean-room design, and it has a legitimate industrial pedigree.
AMD used it in the 1980s and 1990s to reverse-engineer Intel's x86 processors without infringing Intel's copyrighted microcode. Compaq used it to build the first legal IBM PC BIOS clone, which is arguably what made the entire compatible-PC industry possible. Phoenix Technologies made the technique commercially available shortly afterwards. In each case, the method allowed a new team to design a compatible product without touching protected material.
Here is the important part. The clean room is not one team working in ignorance. It is two teams working in careful separation. One team, the "dirty" team, studies the original thoroughly. They read the manuals, they analyse the behaviour, they document what the original does, and they produce a neutral functional specification. The second team, the "clean" team, then designs the new implementation from that specification alone, with no exposure to the original. That is what makes the resulting design legally defensible: the clean team can prove they never saw the protected material.
The developer / product owner I met at the meetup was describing, without perhaps realising it, the clean team's posture. He was leaving out the dirty team entirely.
That is not clean-room design. That is just working in ignorance of the market, which is a different thing. The clean room does not produce creative purity by shielding the designer from information. It produces creative purity by having someone else in the organisation absorb all the information on the designer's behalf, so the designer can then work freely against a neutral summary. Take the dirty team away and you do not get freedom. You get isolation. And isolation produces a specific kind of result: work that was designed in a vacuum, and that will only find out what it collides with when it is already in the market.
The clean room is a two-team method. Anyone claiming its creative benefits with only one team is claiming something the method itself does not offer.
The calculation that made the 80% right in 2018 has two inputs. One is the value of competitor analysis, which has always been genuinely useful. The other is its cost. In 2018 the cost was high enough that skipping it was rational for most independent developers. In 2026 the cost has collapsed by roughly two orders of magnitude.
Some of that collapse is general-purpose. A developer can now open Claude, ChatGPT or Gemini, ask "what apps are similar to mine and what are they doing," and get a plausible answer in under a minute. The answer is limited, it can only see what is on the public web, it cannot see inside an app or reason from live App Store chart data with any depth, but for a first pass it is genuinely useful and it is free. That did not exist in 2018.
Some of the collapse is domain-specific. Appnalysis, the platform this article is published on, was built specifically to answer the questions general-purpose LLMs cannot: what an app actually contains, what it declares, which apps are similar to it not just by category but by architecture and mechanic, what regulatory frameworks apply to it, which apps are climbing toward its category that nobody has thought to add to a watchlist yet. The full analysis I would have paid an agency thousands of pounds to produce in 2018 is now a five-minute question at Ask Appnalysis.
Neither of these tools existed at scale in 2018. Both exist now. Which means the 80% who said no to competitor analysis at WWDC in 2018 were making the right call given the economics of 2018. If they are still making the same call in 2026, they are applying a 2018 calculation to a 2026 environment, and the answer is likely different from what it was.
This is not a moral point. Nobody was wrong to skip competitor analysis when it cost half a day and returned narrow information. The observation is only that the inputs to the decision have changed, and it might be worth revisiting the decision on that basis, rather than by defaulting to what you did last time.
The same shift, applied to the agency version, is subtler but real. An agency that used to price competitor analysis at the level of half a day of analyst time can now include a serious version of it in a delivery for a fraction of that. Which means the argument for keeping it out of scope, that it would raise the brief price and risk the deal, has weakened significantly. It is now the kind of thing an agency can add to their standard delivery scope at very low marginal cost, differentiating their offering rather than inflating the price. Whether they choose to do so is a positioning question, but the economics no longer prevent them.
For readers newer to app analysis, this is the honest answer to the question the article's argument invites.
Four ways to do this today, ordered roughly by depth of what you get back:
Manual research. Google, App Store listings, the Wayback Machine, review scraping, feature grids you build in Notion. This is the oldest form of mobile app market research, and how most teams still start. For very small work it remains valid. It becomes prohibitive at any scale.
General-purpose LLMs. Claude, ChatGPT and Gemini with web search enabled. Fast, free or low-cost, useful for surface questions like "what are the leading apps in category X" or "what do reviews of app Y say." Hits a ceiling on questions that require seeing what is inside an app (they cannot), reasoning from live App Store data (they cannot, they see stale snapshots), or interpreting anything a search result did not already summarise for them (they cannot, they can only paraphrase what is already written down).
Traditional app intelligence platforms. Sensor Tower, data.ai, Appfigures. Strong on revenue estimates, downloads, category tracking. If your question is "how much money did competitor X make last quarter," this is where the honest answer is. Less strong on the interpretation layer beneath: what an app actually collects and declares, what mechanic it uses, how it compares by SDK stack or regulatory posture rather than by revenue.
Appnalysis. The platform beneath this article. Built for the questions the other three cannot answer well: what an app actually contains, what data it declares and against which regulatory frameworks, which apps are similar to it by mechanic and technical architecture rather than by category label, which apps are climbing in your space that you would not have thought to watch. Complementary to Claude for a first pass, complementary to Sensor Tower for revenue-specific questions, not a substitute for either but a distinct layer of intelligence they were not built to produce.
If your question is "should I even look at competitors at all," the honest answer is that Claude with web search will now give you a useful first read in five minutes. If your question is "what is actually going on in my category, and what am I not seeing," that is where Appnalysis exists. Both are cheap. Neither was available at scale in 2018.
The developer / product owner I met at the meetup might read this article and still decide not to do competitor analysis. That is a legitimate choice, and I do not think worse of him for it. The instinct he described, the wish for creative distance, is real, and the clean-room method exists precisely to honour that instinct when it is honoured properly. If he wants to work at right angles to the market, that is his prerogative, and there are good reasons a category-defining product might come from exactly that posture.
The observation this article makes is simply that the calculation that made his choice rational in 2018 has changed. The cost of knowing has fallen. The cost of not knowing has, if anything, risen, because the market is now shipping more apps faster, and the pace at which a new entrant can arrive in someone's category has accelerated. The 2026 version of the same choice deserves to be made against 2026 economics, not against the muscle memory of what the trade-off looked like the last time it was worth thinking about.
That is a decision for whoever actually makes it, and it is worth being clear on who that person is. For an indie developer or independent builder working on their own app, it is them. For an agency's client, it is the client, whether the agency has raised the question or not. For a product team, it is the product owner or product manager. Developers usually inherit the answer. Whether they inherit a good one is not up to them. If you are reading this and the decision is yours to make, it should just be one you have made recently, rather than one you made in 2018 and have never revisited.
If you have not looked at your own category in a while, or ever, one prompt is enough for a first read.
Published by Appnalysis. Written by Mark Thomas. Mobile intelligence for the agentic age.