How do you find users who will actually pay for your app?

A founder arrives at a first meeting with a spreadsheet. It is colour-coded, well-organised, and maps every competitor product in the space. They are visibly pleased with it. We had exactly this with a pre-launch founder in the football industry, who had spent weeks charting rival apps with the aim of combining them into one product. The spreadsheet told him everything about what already existed. It told him almost nothing about who would actually pay for what he was building.

Finding paying users requires asking different questions than finding people with the problem.

That gap, between what a founder knows about the market and what they know about the specific person who will hand over money, is where most consumer apps quietly fail. CB Insights' post-mortem research across failed startups finds that 42% cite no market need as the primary cause, making it the single most common reason, ahead of running out of cash. The problem is that founders work hard on the wrong question.

The right question is not "does this problem exist?" It is "who experiences this problem so acutely that they will pay to solve it, and what does their behaviour already tell us about that?" Those are user research questions, and they have specific answers. This article is about how to find them.

Why 'Everyone Who Has This Problem' Is Not a User Segment

The football founder's spreadsheet was full of competitor products. What it lacked was a single row for a real person. When we started asking questions, the deflation was immediate. Why would someone choose an all-in-one product over three specialised apps they already use and trust? Would consolidating features mean dumbing each one down? Who, specifically, finds the current fragmentation painful enough to switch? There were no answers, because the research had never gone in that direction.

This is the pattern we see with founders who have personal experience of a problem. It is very easy to think "I have this problem, therefore everyone has this problem", and that is simply not the case. A problem being real does not make it universal. A problem being widespread does not make everyone who has it a viable customer. The relevant question is whether enough people experience it acutely enough, and in circumstances that make them open to paying for a fix.

"Everyone who struggles with X" is a description of a condition, not a segment. A segment has behaviours, contexts, and spending patterns you can observe. A condition tells you nothing about who is likely to act on it, how much friction they will tolerate during sign-up, or what price point triggers a decision. Before any of that is understood, a founder does not have a target market. They have a hypothesis.

Before you describe your target user, write down three things they already pay for that are adjacent to your product. If you cannot name them, your user research has not started yet.

What a Paying User Actually Looks Like Before You Have Any

Before a single paying user exists, a founder's best tool is behavioural inference. The question is not who says they would use the product, but who is already spending money, time, or effort on an imperfect version of the same outcome. That behaviour is the signal. Stated intent is almost worthless as a predictor. When users are asked whether they would use an app, 60 to 80% typically respond positively, but actual usage lands at 10 to 20% in practice. The gap between what people say and what they do is large enough to sink a product.

A paying user profile, built before launch, pulls from four sources. First, who is already spending money on partial solutions: the person buying three separate fitness apps is telling you something about their motivation. Second, what contexts trigger the behaviour: is the problem daily, weekly, or occasional? Daily problems sustain subscriptions. Third, what friction they currently tolerate: someone who has set up a complicated workaround is more motivated than someone who vaguely wishes the problem would go away. Fourth, what they describe as the cost of the problem, not in pounds, but in time, embarrassment, or lost outcomes.

Together, these four things sketch a person you could recognise in a focus group room. They tell you something about willingness to pay before you have priced anything. A founder who can describe their first paying user this precisely, before launch, has done the work. One who describes them as "anyone who cares about their health" has not.

Why Founders Research Competitors Instead of Customers

Competitive mapping feels productive. It produces a document. It requires no difficult conversations. It can be done alone, at a desk, without the risk of hearing something that contradicts the original idea. User research, by contrast, is slower, less tidy, and carries the genuine possibility of revealing that a core assumption is wrong. That risk is exactly why founders avoid it.

The fear is specific. As we heard from the football founder's reaction when we started pressing on user motivation, a spreadsheet cannot push back. It validates whatever the founder already believes, because it was built by the founder. User research introduces a party who has no stake in the idea being right, and that is uncomfortable before a product exists.

A spreadsheet built by the founder cannot push back, and that is precisely why founders build them.

The result is that founders arrive with detailed knowledge of competitor features and very little knowledge of the specific person they are building for. When we ask whether there is evidence beyond the founder's own experience that a real need exists, the conversation often stalls. That is the moment to use focus groups or surveys to sanity-check the assumption before committing budget to a build. The competitive map can wait. Talking to ten real people who have the problem cannot.

Run at least five user interviews before you build a feature list. Ask people to walk you through how they currently handle the problem, not whether they would use your solution. Observed behaviour is more useful than stated preference.

How to Run User Research That Finds Willingness to Pay

Most user research is designed to find out whether people like an idea. Research that finds willingness to pay is designed differently. It is looking for pain, not approval.

Questions that surface real motivation

The most useful questions are about cost and consequence, not preference. Ask someone how the problem affects them on a bad day. Ask what they have already tried. Ask what it would mean to have it solved reliably. Ask whether they have spent money on partial fixes and, if so, how much. These questions surface the emotional weight of the problem, and emotional weight is what drives payment decisions.

Reading the signals correctly

In focus groups, the signals worth watching are unprompted elaboration, moments where participants describe consequences you had not anticipated, and the language they use to frame the problem. If ten people describe the same frustration in similar words, that language belongs in your product's copy and your onboarding. If only two people seem genuinely animated about the problem, that is data too.

The structure of a useful research session moves through three phases. First, understand the current behaviour without mentioning your product. Second, explore the problem in depth, including how it has been handled badly before. Third, introduce the concept and watch the reaction, noting what questions people ask rather than whether they say they like it. Questions about price, about reliability, and about specific features they would need signal a different level of interest than general enthusiasm.

Looking Outside Your Target Market to Understand It

On the concierge app we built for a high-end property development, the target customers were high-net-worth residents in a luxury high-rise. We ran focus groups with them. We also ran focus groups with people from social housing, who would never be customers of this product. That second decision changed the entire direction of the project.

The social housing residents had what we were trying to build into the product: a genuine sense of community, belonging, and neighbourliness. Residents in high-rises rarely know each other. The property developer wanted an app to solve that, but the high-net-worth groups could not articulate what made community feel real, because many of them had never experienced it in a residential context. The social housing group had, and they showed us exactly what it looked like.

What we found was that the meaningful quality in their environment came from depth of conversation, not frequency of interaction. People knew each other's actual circumstances. That insight reshaped the product entirely. Instead of automating all communication, we redesigned the app to handle mundane transactional tasks, maintenance requests, fire drill procedures, recycling locations, while creating space for the kind of personal connection that the concierge and neighbours could have with each other. The product became simpler and more focused as a result.

The principle generalises. If you are building for a premium wellness user, a research session with someone who has managed a health condition on a tight budget will surface motivations and anxieties that your target market shares but will not verbalise. The non-customer often embodies the quality you are trying to create, in a form that is easy to observe and hard to miss.

When Your Research Points Somewhere You Did Not Want to Go

The property developer who came to us with a pre-formed idea of what the concierge app should do had a specific budget and a list of features. The discovery process, including focus groups and user workshops that we persuaded them to undertake properly rather than skip, revealed that the product should be considerably simpler than envisaged. A significant number of the planned features were dropped. The scope narrowed. The result was a better product at a lower cost, because the research told us what the user actually needed rather than what the founder had assumed.

That outcome required the client to accept findings that ran against their initial position. Not all clients can do that. We identified a pattern across two other projects, a fitness and wellness app and a grassroots football product, where founders with strong personal conviction ignored data coming out of research, focus groups, and surveys. The product continued to reflect the founder's preferences rather than the user evidence. Warning signs accumulated: excessive time spent perfecting details before launch, decisions being revisited after sign-off, prolonged deliberation at every stage.

Both those projects exhausted their budgets in the design and build phases without ever reaching a fully live product. The question that tends to cut through, and that we ask early now, is this: are you solving a real problem that people will pay for, or are you in love with the solution? The answer separates products that will find a market from products that exist to satisfy the person who built them.

How Early UX Decisions Lock In the Wrong User

The users a product attracts in its first weeks are shaped almost entirely by early UX decisions. The reading age of the onboarding copy, the complexity of the setup flow, the order in which features are introduced, and the questions asked during orientation all signal who this product is for. Get those signals wrong and the right user bounces before they understand what the product does. Get them right for the wrong user and the retention data will mislead you for months.

We worked on a fitness product where early abandonment was high. The orientation required users to answer a series of questions before they could begin, and a meaningful proportion of users dropped out during that process. The change that made the difference was simple: we told users at the start of the orientation how long it would take. That single piece of framing allowed people to enter the process in a more prepared state. They knew what they were committing to. Abandonment fell. The feature itself did not change at all.

That example matters because it illustrates how much early UX shapes the user's emotional state before they have experienced any real value. An orientation that feels endless, or that does not explain why the questions are being asked, selects for a particular type of user: one with high patience and high motivation. If that is not your target user, the retention data will show you a cohort that does not represent the broader market you are trying to reach.

Map the first three minutes of your product experience and identify every moment where a user could reasonably give up. At each point, ask whether the product has yet given them a reason to stay. If not, the problem is sequencing, not the feature set.

The Vanity Product: What Happens When Founders Ignore the Evidence

The fitness app and the grassroots football product shared a trajectory we recognised at the time and flagged to both clients. In each case, the founder had a clear and personally felt sense of what the product should be. Research findings that contradicted that sense were absorbed without changing the direction. Decisions kept being revisited. The scope kept expanding to accommodate the founder's vision rather than contracting toward what users had actually said they needed.

The term we use internally for this outcome is a vanity product: a product built primarily to satisfy the person who created it rather than the market it is meant to serve. The evidence does not disappear in this process. It sits in the research documents and focus group notes, but it stops influencing decisions. The founder's conviction fills the space that evidence should occupy.

Both projects ran out of budget in design and build without reaching a live product. The money was spent on refining something that had not yet been tested with the people it was built for. That is the practical cost of ignoring research: not a bad product launch, but no launch at all. The question of whether you are solving a real problem people will pay for, or whether you are in love with your own solution, is worth asking before the build starts, not after the budget is gone.

Scoping Your Product Around the User You Have Found

Once research has produced a credible picture of who the paying user is, the next step is the one that feels most counterintuitive: removing things from the product rather than adding them. The concierge app ended up simpler than the property developer had envisaged, because the research showed that complexity did not serve the user. Features that had seemed essential in the planning phase turned out to be solving problems the user did not have, or replicating systems the building already had in place.

Scoping around a real user means asking, for every feature, whether the specific person you have identified through research would encounter this problem, feel this problem as a priority, and use this solution in their actual context. That test removes a large number of features from most initial product scopes.

What a scoped product looks like

A product scoped around a real user has a short core flow that delivers the primary value without detours. Secondary features exist to extend that value, not to demonstrate what the product is capable of. The onboarding reflects the user's actual starting knowledge. The language matches how they describe the problem in their own words, not how the industry describes it.

Why simpler products find paying users faster

Consumer app revenue builds over time through retention and growth, not through pricing that reflects the cost of building. A simpler product launched to the right user converts that user faster, retains them longer, and generates the data needed to extend the product sensibly. A complex product built for a user who has not yet been clearly identified tends to convert nobody in particular and retain nobody well. The path to a paying user runs through clarity, and clarity comes from research that was willing to hear difficult things.

Conclusion

Finding users who will pay for an app is a research problem before it is a product problem. The football founder's spreadsheet, the property developer's feature list, the fitness founder's personal conviction: all of them were substitutes for the harder work of understanding a specific person well enough to know what they will actually pay for.

The research that does that work is not expensive or technically complex. It requires talking to the right people, asking about behaviour rather than preference, and being willing to hear findings that change the direction of the product. The concierge app became better and cheaper because the client accepted what the research said. The two products that ignored their research findings never launched.

A useful orientation question to carry into any product discussion is whether the product is solving a real problem people will pay for, or whether it is something the founder is in love with. Sitting with that question seriously, before a build starts, saves the budget that otherwise gets spent refining something the market was never waiting for.

The user who pays exists. Finding them requires looking in the right places, asking the right questions, and being prepared for the answers. If you are at the stage where that work is the next step, let's talk about your product.

Frequently Asked Questions