How Can I Ask Users About Money Without It Being Awkward?

Most users will lie to you about what they'd pay for your app. I mean, not intentionally—but they will. Actually, research shows that self-reported willingness to pay can be off by as much as 60% compared to what people actually spend when its time to pull out their credit card. Which is a problem, right? Because if you're building an app and trying to work out what to charge, asking users directly seems like the obvious thing to do. But here's the thing—people are terrible at predicting their own behaviour when it comes to spending money.

I've spent years working with clients who've built entire pricing strategies around what users told them they'd pay, only to launch and find out the reality was completely different. Sometimes users say they'd happily pay £10 a month, then baulk at £2.99. Other times they claim they'd never pay for an app, but when you frame it differently or offer the right features, they sign up without hesitation. Its a bit mad really, but understanding why this happens—and how to work around it—is one of the most valuable things you can learn about psychology driven app development.

The gap between what people say they'll pay and what they actually pay isn't about dishonesty; it's about the disconnect between hypothetical scenarios and real purchasing decisions.

This guide is going to walk you through how to have conversations about money with your users without making everyone uncomfortable. We'll look at when to ask these questions (and when not to), how to frame them so you get useful answers, and most importantly, how to test real willingness to pay rather than just asking people what they think. Because honestly? What people think and what people do are often two very different things, and your app's success depends on understanding that difference.

Why Talking About Money Feels So Uncomfortable

I've watched hundreds of user interviews over the years, and there's always this moment—this weird tension—when the topic shifts to pricing. The researcher gets a bit fidgety, starts hedging their questions with apologies, and suddenly everyone in the room feels like they've brought up something they shouldn't have. It's a bit mad really, because we're literally trying to understand if people will pay for our product.

The discomfort comes from a few places. First, talking about money triggers social anxiety that goes way back. We're taught from a young age that discussing finances is somehow rude or invasive. When you ask someone what they'd pay for something, it feels like you're asking them to reveal their financial situation—which in a way, you are. Nobody wants to admit they cant afford something, and nobody wants to look cheap either.

But here's the thing—this awkwardness actually ruins our research. When we dance around pricing questions or apologise before asking them, we signal to users that this topic is uncomfortable and they should probably tell us what we want to hear instead of the truth. They'll say they'd "definitely pay £20 a month" when really they mean "I'd think about trying it if it were free."

There's also this weird power dynamic at play. The researcher knows something the participant doesn't—that there's a "right" answer the company wants to hear. Users pick up on this and adjust their responses accordingly. They want to be helpful, they want to be liked, and they certainly don't want to disappoint you by saying your app isn't worth what you think it is.

What Makes Money Questions Different

Money questions are different from other research topics because they require participants to make real judgements about value and their own resources. When you ask someone if they like a blue button or a green button, theres no personal cost to their answer. When you ask what they'd pay? That's different. They're now evaluating:

• Their own budget and financial priorities
• How much they value the solution you're offering
• What competitors charge for similar products
• Whether they want to appear generous or frugal
• If their answer might influence the actual price

The solution isn't to avoid these questions—its to reframe how we approach them. Once you understand why the discomfort exists, you can design your research to work with mobile app psychology rather than against it. And that starts with timing, framing, and creating safe spaces where honest answers feel natural rather than confrontational.

When to Ask About Pricing During Research

Right, so here's the thing—timing matters quite a bit when you're bringing up money with users. Ask too early and you'll get completely useless answers because people don't understand what they're even paying for yet; ask too late and you've already committed to a direction that might not work commercially. Its a bit of a balancing act really.

I've found the sweet spot is usually after users understand the value proposition but before theyve formed strong expectations about what it should cost. This typically means waiting until theyve seen a prototype or demo, played with the core features, and genuinely understood what problem you're solving for them. Because here's what happens otherwise—if you ask someone "would you pay for an app that helps you organise recipes" without showing them anything? They'll say no or throw out some ridiculous number like 99p because they dont really know what you mean.

The Research Timeline That Actually Works

In my experience, pricing conversations should happen in stages throughout your research rather than as one big awkward chat. Early on you want to understand what people currently pay for similar solutions (if anything), then once theyve experienced your concept you can explore what they'd be willing to pay. Finally—and this is important—you need to test actual behaviour with real prices, not just ask hypothetical questions.

Never ask about pricing in your first conversation with a user. Let them experience the value first, even if its just through mockups or a simple prototype. You're not hiding information from them; you're making sure they can give you informed feedback rather than knee-jerk reactions.

The biggest mistake I see? People running feature validation research and pricing research at the same time. Sure, it saves time but it muddles your data. Users end up evaluating features based on imagined prices, or they anchor their price expectations to incomplete feature sets. Keep these conversations separate where you can—validate that people want what you're building, then figure out what theyll pay for it.

Knowing When Users Are Ready

Watch for these signs that its the right moment to bring up pricing:

• Users can clearly explain the problem your app solves without prompting
• Theyve used enough of your prototype to understand the main features
• They're asking questions about availability or when they can download it
• They mention existing solutions they currently pay for
• Theyve spent at least 10-15 minutes exploring your concept

And look, sometimes you need to ask about pricing earlier in the process because youre validating a business model before investing in development. That's fair enough. Just be aware that early-stage pricing feedback is less reliable and should be combined with other validation methods like looking at competitor pricing, industry standards, and what people actually pay for similar apps today.

How to Frame Money Questions Naturally

The way you ask about money matters more than you'd think. I mean, you can't just jump in with "how much would you pay for this?"—it feels pushy and you'll get rubbish answers. Users will either lowball you because they think it affects what you'll charge, or they'll throw out numbers that sound good but don't reflect what they'd actually spend.

Here's the thing—you need to make the conversation about value, not price. Start by understanding what they're currently doing to solve this problem. Are they paying for something already? How much time does it take them? What's frustrating about their current solution? Once you've established the context, money questions feel less jarring because they're part of a bigger picture.

Instead of asking "what would you pay?", try these approaches:

• "What do you currently spend on [similar solution or problem]?"—this grounds the conversation in reality, not hypotheticals
• "If this saved you [specific amount of time/money], what would that be worth to you?"—connects price to concrete benefits
• "Would this be something you'd expense at work or pay for personally?"—helps you understand their budget category
• "How do you typically make decisions about spending on [category]?"—reveals their purchase process and priorities
• "What would make this feel like a no-brainer purchase?"—shifts focus to value proposition rather than raw price

I've found that asking "is this cheaper, about the same, or more expensive than you expected?" after showing a price point gets you honest reactions without the awkwardness. People are comfortable comparing things;they struggle with naming exact figures out of nowhere. And honestly? The discomfort you feel asking about money is usually worse than what your users actually experience answering it.

Different Research Methods for Different Goals

Right, so here's where it gets interesting—there isnt one magic research method that works for every pricing question. I mean, if there was, my job would be a lot simpler! What you need to figure out first is what you're actually trying to learn, because that determines how you should ask.

If you're in the early stages and just want to understand whether people would even consider paying for your app, you want qualitative methods. User interviews are brilliant for this because you can have a proper conversation about value before you even mention price. You know what? Some of my best pricing insights have come from asking "what would make this worth paying for?" rather than "how much would you pay?" It's a subtle difference but it completely changes the dynamic.

Surveys for Scale, Interviews for Depth

Once you've got a sense of the value proposition, surveys let you test specific price points with more people. The Van Westendorp Price Sensitivity Meter works well here—you ask four questions about price thresholds (too cheap, reasonable, expensive, too expensive) and it helps you find that sweet spot. But be careful; surveys only work if people actually understand what they're getting.

The best pricing research combines what people say with what they actually do

Testing Real Behaviour

And then there's behavioural testing, which is honestly the most reliable method but also the trickiest to set up. This means showing real prices to real users and seeing what they do. A/B testing different price points on your landing page or in a prototype with payment screens gives you actual data about willingness to pay, not just opinions. I've seen cases where users said they'd happily pay £9.99 in an interview but the conversion data showed £4.99 was the optimal price point. Actions speak louder than words, basically.

What to Actually Ask Users

Right, so you've got your users in front of you—now what? The specific questions you ask make all the difference between getting useful insights and complete rubbish. I've tested dozens of approaches over the years and some work far better than others.

Start with context before you dive into pricing. Ask them about their current solution first; what are they using now and what does it cost them? This isn't just small talk—it anchors their expectations and gives you a baseline. If someone's currently paying £50 a month for a similar service, suggesting £5 or £500 is going to feel very different to them.

Here's the thing though—dont ask "Would you pay £X for this?" Its a terrible question because people will either lie to be nice or say no to avoid commitment. Instead, try these:

• What would be too expensive for this? At what price would it feel like a bargain? (Van Westendorp method—gets you a range)
• How much do you currently spend on solving this problem? (Reveals their existing budget)
• If this was £10 per month, what features would you expect? What about at £50? (Shows what drives value perception)
• Which of these three pricing tiers feels right for you and why? (Forces comparison thinking)
• What would stop you from buying this at £X? (Uncovers objections beyond just price)

Also, pay attention to how quickly they answer. A fast "no" usually means the price is genuinely too high, but hesitation? That often means they're interested but negotiating with themselves. I've seen this pattern hundreds of times and its surprisingly reliable.

And here's something most people get wrong—always ask about payment frequency preferences too. Some users will happily pay £100 annually but balk at £10 monthly, even though the monthly option is more expensive overall. It's not always about the total amount; it's about how it fits into their mental accounting and cash flow.

Reading Between the Lines of Price Feedback

Here's what nobody tells you about pricing research—what people say and what they actually mean are two completely different things. I've sat through hundreds of user interviews over the years and honestly, its become second nature to translate what users are really saying when they talk about money. The trick isn't just listening to their words; it's watching how they react, noticing their pauses, and understanding the context behind their answers.

When someone says "that seems expensive," what they're often actually saying is "I don't understand the value yet" or "I've seen something cheaper elsewhere." But here's the thing—they might also be saying "I love this but need to justify it to my boss" or even "I'd pay that, I just want to negotiate first." You need to dig deeper. Ask them what they're comparing it to. Ask them what would need to change for the price to feel fair. Those follow-up questions reveal so much more than the initial reaction.

What Different Responses Actually Mean

I've learned to categorise responses based on how users deliver them, not just what they say. Quick agreement on price? That usually means you're undercharging—people expect some hesitation in pricing conversations. Long pauses followed by "yeah, that's reasonable"? They're probably at their limit but willing. Immediate pushback with specific competitor pricing? They've done their homework and you need to clearly differentiate your value. And when someone says "I'd need to think about it"...well, that's often a polite no unless you can address their concerns right there.

Body Language and Tone Matter More Than You Think

Even in remote interviews, you can pick up on vocal cues. Someone who goes quiet after hearing your price is processing—give them space to think. Someone who immediately starts explaining why they cant afford it might actually be interested but genuinely has budget constraints. The key is distinguishing between "no because its not worth it" and "no because I literally don't have the money right now" because those require completely different solutions.

Record your pricing research sessions (with permission obviously!) and watch them back without sound first. You'll notice reactions you missed during the conversation—facial expressions, body language shifts, and timing tells that reveal their true feelings about your pricing before they've had time to filter their response.

One pattern I've noticed is that B2B users and consumer users give completely different types of feedback. Business users tend to be more direct about budget constraints but also more willing to discuss value propositions. Consumer users are often more emotional in their responses—they'll say things like "I wouldn't pay that" when what they mean is "I don't pay for apps generally" which is useful information but very different from actual price sensitivity.

Here are the most common hidden meanings behind typical pricing feedback:

• "That's more than I expected"—they had a specific competitor or alternative in mind as their reference point
• "I'd have to see it working first"—they don't trust that you'll deliver on your promises, not necessarily that the price is wrong
• "How much is the annual plan?"—they're interested but want to see if they can get a better deal
• "What features are included?"—they're trying to justify the price in their head by calculating value
• "Is there a free version?"—they might convert to paid later but need to test first, or they genuinely will never pay
• "That seems reasonable"—could mean anything from "I'd pay double" to "I'll probably choose the cheaper option"

The context around these responses matters too. If someone asks about annual pricing within seconds of hearing monthly pricing, they're already mentally committing. If they ask about features before reacting to price, they're value-focused shoppers who can be won over with the right positioning. And if they immediately compare you to a competitor, they're shopping around—you haven't differentiated yourself enough yet.

Something I always watch for is whether users use "I" or "we" language when discussing price. "I think that's too much" is personal opinion; "We couldn't justify that cost" suggests organisational constraints or purchasing processes you need to understand. In B2B especially, the person you're talking to often isn't the person who controls the budget, so their feedback might reflect their boss's likely reaction rather than their own opinion.

Testing Real Willingness to Pay

Here's where things get interesting—you can ask people what they'd pay all day long, but actual behaviour tells a completely different story. I mean, I've lost count of how many times users have told me they'd "definitely pay £9.99 a month" only to balk when presented with an actual payment screen. It's not that they're lying; its just that hypothetical money and real money are two very different things in people's minds.

The best way to test willingness to pay? Get as close to a real transaction as possible without actually charging them (unless you're ready to deliver, of course). I've used pre-order campaigns, waiting lists with pricing tiers, and even Kickstarter-style campaigns to gauge actual interest. When someone has to enter their card details—even if you're not charging immediately—their commitment level becomes crystal clear really quickly.

But here's the thing—you don't always need a full payment flow to test this. You can use what I call "soft commitment" tests that still reveal genuine interest:

• Landing pages with different price points and measuring conversion rates to signup forms
• Email campaigns that ask users to "reserve their spot" at specific pricing tiers
• Beta programmes where users get early access but commit to a future paid plan
• Feature gating that shows pricing before users can continue (even in prototypes)
• Surveys that require progressively more effort as prices increase, mimicking real purchase friction

What you're looking for is drop-off points. Where do people stop engaging? At what price does enthusiasm suddenly disappear? I've seen apps that tested beautifully at £4.99 completely fall apart at £6.99—and that £2 difference tells you everything you need to know about your market positioning.

One method that works particularly well is the "good-better-best" pricing test. Show three tiers and watch which one gets the most interest; people naturally gravitate toward what they perceive as fair value, and their choices reveal their actual budget constraints better than any survey question ever could. This approach is particularly effective when combined with different app monetisation strategies to see which pricing models resonate with your audience.

Common Mistakes That Skew Your Results

Right, lets talk about the things that mess up your pricing research—because honestly, I see these same mistakes over and over again. The first big one? Asking hypothetical questions instead of making things real. When you ask someone "would you pay £9.99 for this?" their brain doesn't have to make an actual decision, its just playing pretend. And people are rubbish at predicting their own behaviour when there's no real consequence.

Another trap is talking to the wrong people entirely. I mean, if you're building a professional tool for designers but you're interviewing your mates who work in retail, your pricing data is going to be wildly off. You need to speak to people who actually have the problem you're solving and—this is the bit people forget—who have the authority to spend money on solutions.

Leading Questions Kill Your Data

Here's something I see all the time: researchers accidentally leading their participants toward a specific answer. Saying something like "this premium feature only costs £15, which is pretty reasonable, right?" well, you've just told them what answer you want. Instead, present the price neutrally and let them react naturally. Their face will tell you more than their words sometimes.

The moment you tell users what you think is reasonable, you've contaminated your entire research session

Sample Size and Selection Bias

Look, I get it—research takes time and recruiting participants is hard. But talking to just three people who all found you through the same channel isn't going to give you reliable pricing insights. You need diversity in your research group: different industries, different company sizes, different budget levels. And please, don't only interview people who already love your product because they're going to tell you they'd pay anything. That's not representative of the wider market you're trying to reach.

The last mistake? Not testing your pricing in context. Showing someone a price on a slide in an interview is different from them seeing it on your actual checkout page after they've gone through your onboarding flow. Context matters massively when it comes to perceived value. This is where understanding how app size affects pricing expectations becomes crucial for setting realistic benchmarks.

Conclusion

Look—asking people about money is never going to feel completely natural, and honestly? That's fine. I've been doing user research for mobile apps long enough to know that a bit of awkwardness is just part of the process. The key isn't to eliminate that discomfort entirely; its about managing it in a way that still gets you the information you need to price your app properly.

What I've learned over the years is that users actually want to talk about pricing more than we think they do. They just need the right environment and the right questions. When you frame money discussions around value—what they're getting, what problems you're solving, what alternatives they're comparing you to—the conversation shifts from awkward to genuinely useful. And that's what we're after, right?

The biggest mistake I see developers make is avoiding pricing conversations altogether because they feel uncomfortable. But here's the thing—if you don't ask about money during research, you're basically guessing when it comes time to launch. And guessing wrong can kill your app faster than a bad review. I've seen brilliant apps fail because they were priced too high, and I've seen decent apps leave thousands on the table because they were priced too low.

So yes, asking about money might feel a bit awkward at first. You might stumble over your words or get some responses that don't quite make sense. That's normal. But with the techniques we've covered—timing your questions right, framing them naturally, using the right research methods, and learning to read between the lines—you'll get better at it. You'll start to hear what users are really saying about value, not just what they think you want to hear. And that's when you'll finally have the confidence to set a price that reflects what you've built and what your users are genuinely willing to pay for it.

Frequently Asked Questions