How to Check if Your App Idea Exists?

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet. Every competitor product in his market was mapped across tabs, with a plan to merge several of them into one app. He was excited, and pleased with himself, and he'd done more homework than most people who walk through our door. When you set out to check if an app idea exists, that spreadsheet is usually what you end up holding, and it answers a smaller question than you think it does.

A competitor list tells you what has been built, never what people actually want.

We started asking about his prospective users. Why somebody would pick one app that does five things over five apps that each do one thing properly. Whether merging them risked dumbing down the individual features people already liked. He deflated, and that's never a nice thing to watch, but it's our job to be honest about what makes a product succeed.

So this piece walks through how to search properly, where to look once the app stores run dry, and what to do with what you find. The short version is that finding competitors is good news. Finding nothing at all is the result that should give you pause.

What You Are Actually Checking For

Most people run this search looking for a mirror image of their idea. They want to know whether somebody has already built the exact thing, with the same features, pointed at the same people. That's the narrowest version of the question, and a clean result tells you very little.

Three questions hiding in one

Pull them apart and you get something more useful. Does a near-identical product exist? Is the need already being met in some other way? And how do people feel about meeting it that way right now?

That third one does the heavy work. As Simon puts it, "we're always taking a step back and thinking about what need is the product going to fill? How do they feel about that? There's no point building a technical solution for something that people are quite happy doing in a more manual process." A person juggling four apps and a notes file is annoyed. A person using one spreadsheet once a month is fine, and no amount of design will make them want your app.

Skipping the search altogether is common enough. Meegle puts the share of startups with almost no visibility of their rivals at 44 per cent, which is a lot of people building in the dark.

Searching the App Stores Properly

App store search is poor, and it rewards the words developers chose rather than the words users would type. Search "football club admin" and you get nothing. Search "team manager" and you get thirty results, half of them for rotas in restaurants.

Check if an app idea exists

Work through it in this order.

1. Search the problem in a user's words, then in a developer's words, then in the words your mum would use.
2. Run the same searches in the App Store and on Google Play separately, because the results differ.
3. Repeat in every country you plan to launch in, since rankings and listings are regional.
4. Read the category charts, both top free and top grossing, rather than only search results.
5. Note the apps that rank for your terms while doing something else entirely. Those are the ones users will see first.

With over six million apps sitting across the leading stores, according to Statista, a blank search result usually means your keywords are wrong rather than the category is empty. Give it an afternoon, not ten minutes. Keep every app you find, including the ones you think are bad, because bad incumbents shape what users expect.

Looking Beyond the App Stores

Plenty of products that compete with you have no app store presence at all. They're web tools, Slack bots, WhatsApp communities, Notion templates, or a service run by three people with a spreadsheet and a phone number. When founders ask us how do I find out if my app idea exists, the honest answer is that the stores are the easiest place to look and the least complete.

Spread the search across sources that show different things.

Dead products matter too. If three companies tried this between 2018 and 2022 and all folded, that's the most valuable thing your search will turn up.

A product that never reached the app store can still have taken your market.

Write down what killed each one, as far as you can tell. Price, distribution, timing, or nobody caring. Then ask what's different for you.

Checking Adjacent Markets and Indirect Competitors

Your real competition is whatever people do today instead of using your app. For a lot of ideas that's a group chat, a paper diary, a phone call, or just living with the annoyance. Nothing in an app store will tell you that, and it's the thing most likely to beat you.

Adjacent markets matter for the same reason. We worked on a niche trading platform where no direct equivalent existed anywhere, which sounds like an open goal and isn't. What we did was find products performing some part of what the platform would do, in neighbouring markets, and study those instead. Their features, their pricing, their reviews, the way they described themselves. None of them was the same product, and together they told us what the behaviour around that kind of product looks like.

So build two lists. Direct competitors, meaning products doing broadly your job for broadly your user. Then indirect ones, meaning everything else that currently absorbs the need, including manual habits and general tools like email, spreadsheets and the camera roll.

The second list is the harder read, and it's where you find out whether people are frustrated or quietly content. Content people don't switch.

Patents, Trademarks and Protected Names

Two different checks get muddled here. One is whether somebody owns the idea. The other is whether somebody owns the name.

In the UK and Europe, software as such is generally excluded from patent protection unless there's a genuine technical effect, so the odds of a patent blocking a typical lifestyle app are low. Specific technical methods do get patented, and if your product leans on an unusual bit of engineering it's worth a proper look rather than a guess. A solicitor who does this daily will answer it faster and cheaper than you will.

Names are the more practical risk. Run your name through the UK Intellectual Property Office register, the EUIPO register if you're selling into Europe, and the WIPO Global Brand Database for a wider sweep. Check the class that covers software, and the classes that cover what you actually sell. Then check domains, social handles and whether an identical app name already sits in either store.

Search the trademark registers before you print anything or buy ads. Renaming after launch means new store listings, new URLs and a review score that starts again from zero.

Reading Reviews for What Users Are Not Getting

Competitor reviews are the cheapest user research available, and almost nobody reads enough of them. Ratings are close to useless on their own. The text underneath is where people describe, in their own words, the gap you're thinking about filling.

Start with the one and three star reviews. One star gets you the rage, which is often about billing or a crash. Three star gets you the considered disappointment, which is usually about the product itself. Sort by most recent, because a complaint from 2019 was probably fixed.

Ministry of Programming suggests reading fifty to a hundred recent reviews from each of your top five competitors, which is a sensible working sample. Tag what you find as you go.

• Repeated complaints about the same screen or step
• Feature requests people make unprompted
• Uses the product wasn't designed for
• Words people use for the problem, which become your copy
• Praise, because that tells you what you can't be worse at

Keep a verbatim quotes column. One real sentence from a frustrated user carries more weight in a room than any summary of fifty reviews.

Why Finding Competitors Is Good News

Founders go quiet when they find a product that does most of what they planned. The instinct is that the space is taken. The reality is that somebody else has already spent money proving people want this, and you get that for free.

A market with five funded competitors has demand, a price people accept, and users who've already learned the basic interaction. A market with none has you explaining the category from scratch, which is slow and expensive.

Competitors are proof somebody paid to find out that this market exists.

The thing that kills products isn't crowding. CB Insights puts no market need at the top of its list of startup failure reasons, at around 35 per cent, and Simon uses a similar figure when he argues that market validation is the cheapest check a founder can run and the first one worth doing.

So competitors answer the hardest question before you've written a line of code. What's left is a narrower question about whether you can serve some group of those users better than the people already serving them, and that's a question you can test in weeks.

When Nothing Comes Up at All

An empty search feels like a win and rarely is. Four things cause it, and only one of them is good.

Your keywords are wrong, which is the most likely explanation and the easiest to fix. The product exists under a name you haven't thought of. The market was tried and died, and the evidence has been deleted along with the company websites. Or nobody has built it because there's no money in it.

Before you celebrate, go looking for the graveyard. Search the problem phrase with words like "shut down", "closing", "sunsetting". Check the Wayback Machine for sites that stopped updating. Ask in a forum where your users hang out whether anybody remembers something like this.

Then ask yourself Simon's question, which is the one that separates a market from an obsession. "Are you solving a real problem that people will pay for? Or are you yourself in love with the solution?" That filters out what he calls vanity products, built to satisfy the founder's own picture of things rather than a need anybody else has.

If your search returns nothing, go and find five people with the problem and ask what they do about it today. Their answer is your competitor.

The Limits of a Competitor Spreadsheet

There's a reason pre-launch founders reach for feature mapping rather than user interviews, and it isn't laziness. A spreadsheet is cheap, it's tangible, and nothing in it argues back. It gives immediate validation of opinions you already hold. Simon is blunt about what sits underneath that, which is a worry that research turns up the wrong answer. What if the idea isn't right, and what if nobody wants to use this.

Feature grids also flatten everything into ticks. A competitor either has messaging or doesn't. The grid can't record that their messaging is widely disliked, or that the feature exists but is buried four screens deep, or that the people who use it most are a group you weren't planning to serve.

When we push on this with clients, the point is to add the missing dimension rather than throw out the work. The competitive analysis a founder brings us usually has real value in it. User insight gives that data a different edge, because it explains why the features landed the way they did and which gaps anybody actually cares about.

Turning Your Findings Into a Market Check

Research becomes useful when it changes what you build. The first step is being honest about where each piece of your picture came from, because the sources carry very different risks.

Simon's habit when a client tells us something feels obvious is to ask where that idea comes from. "Is this coming from just the feeling from people in the room. Is it coming from concrete data? Is it coming from analytics." If it's the room, insider bias is almost guaranteed, because people who know a product deeply find flows intuitive that a first-time user finds baffling.

For review mining, Ministry of Programming treats a complaint appearing in 15 per cent of reviews as a signal worth chasing, which is a reasonable line to draw before you start calling a one-off a pattern.

Pricing and Revenue Benchmarks From Comparable Products

Once you know who else is out there, you can stop guessing at revenue. On the niche trading platform, we had no direct equivalent to benchmark against, so we analysed products in adjacent markets that performed some aspects of what the platform would do, looked at their revenue and subscription models, and used those as the baseline for our forecasts.

Then we adjusted. Where a comparable product already had strong traction, we scaled our projections right down, because launching something new into the same space starts from nothing while they start from an existing base.

We scaled the forecasts right down, because a new product starts from zero.

Pull the following from every comparable product you find.

Price tells you what the market has been trained to accept. Moving far above that line needs an argument, and you'll have to make it on the store listing in about eight words.

Building a Case for Difference, Not Just More Features

The common response to a crowded market is to promise everything the incumbents do, plus three extras. That was the football founder's plan, and it's the plan a competitor spreadsheet naturally produces, because a grid full of ticks begs to be filled in.

We worked with a property developer building a concierge app for high-rise buildings who came to us with a budget and a formed idea, wanting a sign-off rather than a scoping exercise. We convinced them to run a proper discovery phase with focus groups and user workshops. What we found was that the product needed to be far simpler than they'd imagined. A lot of planned features came out, and the focus moved to creating a human connection with the product rather than replacing systems the building already ran perfectly well. Better product, lower cost.

Difference also lives in small design decisions. In our search work, we found that giving people example questions, suggested searches or a well-written placeholder gets them past the paralysis of an empty box and towards a query that works. Nobody lists that on a feature grid, and users feel it within seconds.

What Happens When Founders Ignore What They Find

Research only pays off if you're willing to be wrong. We took on a founder with deep industry experience and very strong opinions about how the product should work. The research turned into a box-ticking exercise, because there was never any real intention of acting on it. We showed compelling evidence that large numbers of their potential users didn't want particular features and preferred something else. They didn't move an inch. We walked away from the engagement, and they launched roughly what they'd always planned about a year later. By Simon's account, it went nowhere, for the reasons the research had already flagged.

That's the expensive version of ignoring your findings. The cheap version is quietly reinterpreting them, where a complaint in forty reviews becomes "users just need better onboarding" and nothing changes.

Before research starts, write down what finding would make you change the plan. If you can't name one, you're buying reassurance rather than information.

Building on numbers that only flatter you serves nobody, which is why we'd rather have the awkward conversation at week two than at launch.

Taking the Research Into Discovery

Everything above is desk work, and it's the cheap part. It narrows the questions rather than answering them, and the answers come from talking to people who have the problem.

Gaps in discovery have a habit of reappearing as rework. On a dating app project built around verified profiles and keeping bots out, the client wanted to skip discovery for the messaging side and put everything into onboarding. What we ended up building was a generic messaging feature, and it contradicted the whole premise, because it allowed automated and fake messages straight past all the verification work. That section had to be rewritten, at around fifteen thousand pounds of extra budget and two months of extra time.

So carry your competitor findings into discovery as questions rather than conclusions. Then get something small in front of real users early. Simon's position on this hasn't shifted in years, and it holds up. Getting something imperfect out, testing the market and iterating is cheaper and more effective than trying to build the perfect product from a planning table.

Conclusion

If you set out to check if an app idea exists and you find ten products doing something close, you've had a good day. The demand is proven, the price range is visible, and the reviews are sitting there telling you exactly where those products let people down. Your job narrows to one group of users and one thing you'll do better.

If you find nothing, search harder, then look for the companies that tried and closed. Silence in a market usually has a cause, and it pays to know what it was before you spend a year finding out yourself.

What the desk research can't do is tell you how people feel about the way they solve this today. The football founder had the most thorough competitor map we've seen and still couldn't answer why anybody would leave the apps they already liked. That answer only comes from the people you're building for, and getting it early costs a fraction of getting it late.

If you're working through this and want a second pair of eyes on what you've found, let's talk about your app idea.

Frequently Asked Questions