How Big Is the Market for My Mobile App Idea?

A founder came to us with a colour-coded spreadsheet. Every competing product in the grassroots football space was mapped across dozens of columns, features colour-coded by gap or overlap, and the conclusion was already written: the market was fragmented, users were underserved, and a single app could consolidate the best of everything. The spreadsheet was beautifully made. The founder was visibly pleased with it. And when we started asking questions about why a user would choose an all-in-one product over the specialised apps they already used, the energy in the room shifted. Those questions had no answers yet, because no actual users had been spoken to.

The spreadsheet was beautifully made, but no actual users had been spoken to.

That experience sits at the heart of how market sizing usually goes wrong. The numbers look compelling because the category is large, the competition is visible, and the founder's conviction is genuine. But category size and personal conviction are not the same thing as a reachable market with real demand. The gap between them is where most early-stage mobile products quietly fail, often long before they reach a user's phone. What follows is how to close that gap before you spend a meaningful budget finding out the hard way.

Getting market size right is less about finding a large number and more about understanding what portion of that number you can realistically serve, and whether those people genuinely want what you are building.

Why Market Size Numbers Are Usually Wrong Before You Start

The first number most founders reach for is a top-down market figure: the global fitness app market is worth £14 billion, the e-learning sector is growing at 18% annually, the property technology space is expanding rapidly. These figures come from analyst reports, and they are real. They are also almost entirely useless as a guide to what your specific app can achieve.

Top-down figures describe the total money flowing through a category. They include every player in the space, every geography, every pricing tier, every business model. A founder building a strength-training app for people over 50 in the UK is competing in that global fitness market in the same way a corner café competes in the global food and beverage industry. The category is accurate; the relevance is not.

The deeper problem is that these numbers reward confident storytelling. A large TAM makes a pitch deck look credible. It gives investors something to anchor on. But it does not tell you how many people will download your app, pay for it, or return to it after the first week. Those questions require a different kind of thinking, and they cannot be answered by a market report that was written before your product existed.

Total Addressable Market vs. the Market You Can Actually Reach

Market sizing frameworks distinguish between three layers, and the differences between them matter more than most founders appreciate. The total addressable market is everyone who theoretically benefits from your category. The serviceable addressable market is the portion you could plausibly reach given your geography, platform, and business model. The serviceable obtainable market is what you can realistically capture given your budget, team, and competitive position.

New apps typically capture somewhere between 0.1% and 1% of their addressable market in the first year, according to AppTweak, whereas founders building top-down models often assume 5% to 10%. That gap compounds quickly. A market you size at 10 million users with a 5% assumption gives you 500,000 users. The same market at 0.5% gives you 50,000. The difference between those two numbers changes everything from infrastructure cost to revenue forecast to fundraising target.

The Category Average Problem: When Big Numbers Hide Small Opportunities

Category data flattens enormous variation into a single average. The travel app market includes Booking.com and a niche app for solo female travellers in Southeast Asia. Treating those as the same market for sizing purposes produces a number that describes neither of them accurately.

We worked on a map-based fitness social network designed to connect people for runs and cycle rides. The fitness app category is large and growing, and a naive reading of that market data would suggest a strong opportunity. But the specific behaviour the app required, sharing your location with a stranger to meet for exercise, sits in a much narrower slice of that market. Users who want to track their own runs are not the same users who want to find running partners, and users who want running partners are not all willing to share their location to do it.

A large category average describes the whole market but none of its specific slices.

The category number told us nothing useful about this specific behaviour. What we found from the actual product data was that users were dropping off at the location-sharing step because we were asking for a high-trust action before any trust had been built. After redesigning the flow to introduce approximate proximity first and sequence conversation before location disclosure, conversion from sign-up to successfully meeting another user rose from around 20% to around 60-70%. The market size had not changed. The product's ability to serve it had.

How to Define Your Actual User, Not a Demographic Proxy

Demographic proxies are comfortable to work with. "Adults aged 25-40 with smartphones and an interest in fitness" is a definable segment. It has a number attached to it. It fits neatly into a slide. It is also a description of hundreds of millions of people with almost nothing meaningful in common from a product perspective.

The question that actually matters is behavioural: what does this person currently do, what does that cost them in time, money, or frustration, and at what point in their day or week does your product become relevant? A 34-year-old who cycles to work and a 34-year-old who cycles competitively at weekends are the same demographic. Their relationship to a cycling app is entirely different.

Before you size your market, write out the specific moment your user reaches for your app. What just happened? What did they try before? Why did that not work? If you cannot answer these questions from user conversations, you are not yet ready to size anything.

On the concierge app we built for a property developer, the intended user was anyone moving into a high-rise flat. That is a demographic. The actual user, as focus groups revealed, was someone in a state of mild stress, surrounded by boxes, trying to orient themselves in a new building without wanting to read a manual or speak to a stranger. The product that served the demographic and the product that served that specific emotional state were quite different things.

The Questions That Reveal Whether Demand Is Real

Simon's observation is direct on this: it is very easy to think "I have this problem, therefore everyone has this problem, " and that is simply not the case. A founder who personally experiences a gap in the market has one genuine data point. Before treating that as evidence of broad demand, you need to find out whether others share the problem and whether they experience it as acutely as you do.

The questions worth asking are not "would you use this?" Survey respondents answer that question generously. Research from AppTweak suggests that 60-80% of users say they would use an app, while actual usage typically lands at 10-20%. Stated intent is not demand.

The more revealing questions are about current behaviour. How do you handle this problem right now? What does that cost you? Have you paid for anything to solve it? Would you stop using what you currently do? These questions surface whether the problem is a genuine pain point or a mild inconvenience that nobody would change their habits to address.

Run a short survey before you build anything. Ask ten to fifteen people outside your immediate network how they currently handle the problem your app addresses, and whether they have spent money trying to solve it. The answers will tell you more about real market size than any analyst report.

From the Bottom Up: Sizing a Mobile Market Without Guessing

Bottom-up sizing starts with a specific user doing a specific thing and builds outward from there, rather than starting with a category total and dividing downward. The method is more work, but it produces a number that is actually connected to your product's reality.

The starting point is the specific behaviour your app requires. How many people currently exhibit that behaviour, even in a rough way? How many of those people are reachable through the channels you have? What proportion would plausibly switch to your product, and over what timeframe?

1. Define the exact action your app asks users to take on a regular basis.
2. Estimate how many people currently take that action using any method at all.
3. Identify which of those people you can reach, given your budget and distribution channels.
4. Apply a realistic adoption rate based on comparable products, not on optimistic assumptions.
5. Set a year-one target that reflects those constraints, then test whether that number makes the business viable.

On the property concierge app, we convinced the developer to work through this process in a proper discovery phase rather than jumping straight to build. What the discovery revealed was that the product needed to be far simpler than originally envisaged. Many planned features were dropped, and the focus shifted to creating a human connection with the product rather than replacing existing building systems. The result was a better product at a lower cost, sized to what users actually needed.

What Competitors' User Numbers Actually Tell You

Competitor data is a legitimate starting point for market sizing, and it is more useful than category reports because it reflects revealed behaviour rather than projected demand. If three apps in your category each have 200,000 active monthly users and a fourth has 2 million, that tells you something real about the ceiling of demand and the distribution of attention.

But competitor user numbers also mislead if you read them as confirmation that the market is large enough for another entrant. What they actually show is that those users have already found a solution. The question is not whether the category has users, but whether enough of those users are sufficiently dissatisfied with what they have that they would switch to something new.

There is substantial research showing that feature parity alone does not drive switching. Having the same or even better features than a competitor does not guarantee adoption. What matters is understanding the specific use case, the emotional context, and what it would take for a user to change a habit they have already formed. A new fitness app with identical functionality to an established one needs a reason for users to bother, and "slightly better" is rarely sufficient.

When you look at a competitor's app store reviews, sort them by one and two star ratings and read the most recent 50. These are the users who have already tried the product and found it lacking. Their specific complaints are your most honest view of unmet demand.

When the Spreadsheet Looks Good but the Opportunity Isn't There

The grassroots football app we worked on never reached market. The client came in with a vision for consolidating several existing apps into one product, and the category logic seemed sound: fragmented supply, users switching between multiple tools, an obvious aggregation opportunity. The spreadsheet case was coherent.

We advised launching a limited feature set first, testing the market, and growing from there. The client wanted to build everything at once. Scope kept expanding, budget kept rising, and the product became unnecessarily complex at every stage. It never launched. The market opportunity, whatever it was, remained entirely theoretical.

This is a pattern worth naming directly. A spreadsheet that shows a large addressable market, a clear gap in competitive offerings, and a plausible revenue model can all be true simultaneously with an opportunity that does not actually exist in practice. The football app case was not a failure of market sizing. It was a failure of product discipline, but the two are connected: when you believe the market is large enough to absorb a complex product, you stop making the hard decisions about what to cut.

The test is whether the specific user you are targeting will change their behaviour, and whether you can reach them before your budget runs out.

Validating Market Assumptions Before You Build

Market validation does not require a finished product. It requires a specific claim about user behaviour and a method for testing whether that claim holds before you invest in building around it.

The most common objection to this is sample size: a small number of conversations or survey responses cannot prove a market exists. Simon's approach here is direct. Any number of participants adds value over none, and if the findings point to fundamental changes, those should be put on the table and assessed for their business impact. If the concern about sample size persists, the right move is to shift from exploratory qualitative work into larger-scale quantitative validation through predefined surveys, which can reach far more people than one-to-one sessions.

What this means in practice is that validation is a sequence, not a single event. Early conversations reveal the shape of the problem. A focused survey tests whether that shape holds at scale. A prototype or landing page tests whether people take an action, not just express an opinion. Each stage narrows the uncertainty before the next one begins.

• Qualitative interviews to understand the problem and the user's current behaviour
• Quantitative survey to test whether the pattern holds beyond the initial sample
• Prototype or concept test to measure willingness to act, not just to agree
• Limited release to gather real usage data before committing to full build

Getting something imperfect to market and iterating is always cheaper than attempting to build the perfect product from the start. The founders who resist this tend to believe their market is too clear to need testing. That belief is the most expensive one in product development.

Conclusion

Market size is a genuinely useful thing to understand. It is worth knowing whether your category has 50,000 potential users or 5 million, because that changes everything from pricing to distribution to how much you can afford to spend acquiring each one. The problem is that founders size their market using numbers that were never designed to answer the question they are asking.

The category total, the competitor's download count, the analyst report from three years ago, these are context, not answers. The answer comes from understanding a specific user with a specific problem in a specific moment, and finding out whether enough of those users exist, can be reached, and will act. That work is slower than reading a market report. It is also the only work that produces a number you can build on.

The football founder with the colour-coded spreadsheet had done real work. The spreadsheet showed genuine thinking about the competitive landscape. What it could not show was whether any real user wanted the product it described, because no real user had been asked. That is the gap between a market that looks large and a market that is actually there.

If you are at the stage of asking how big your market is, the most useful next step is a conversation about what you actually know about your user and what it would take to find out. Let's talk about your app and what the market evidence really shows.

Frequently Asked Questions