How Do I Find Out What Price Users Will Pay for My App?

The short answer is that you find it out three ways at once, and you only trust the number when all three agree. You look at what people already pay for things like your app, you ask a structured set of pricing questions to people who match your audience, and then you put a real price in front of real users and watch what they do with it. App willingness to pay sits where those three overlap, and any one of them on its own will mislead you.

Price is a design decision, and people read it with the same eyes they read everything else on screen.

We say that because we've watched what happens when price gets treated as an accounting exercise instead. On a music backing track app, the client knew to the penny what the recordings had cost to make, and the price came straight off that figure. Sales were low, which is what we'd told them to expect.

What follows is how we get to a defensible number, drawn from pricing work on apps across travel, marketplaces, messaging and trading. Some of it is research you run before a line of code exists. Some of it only shows up in live data after launch. All of it is cheaper than guessing.

What Willingness to Pay Actually Measures

Willingness to pay is the most a person will hand over for your app at a given moment, in a given context, with a given set of alternatives sitting in their head. Change any one of those and the number moves. Someone looking at a running app in early January is carrying a different number to the same person in June, and the app hasn't changed at all.

Stated price and revealed price

There are two quite different things being measured here, and teams mix them up constantly. Stated price is what people tell you in research, and it's useful for direction, ranges and comparisons between options. Revealed price is what happens when money actually leaves someone's account. You plan with the first and you build the business on the second.

The other thing worth saying is how little time this usually gets. According to Invesp, most SaaS companies spend around six hours developing their pricing model, which is less than a single round of user interviews. For a decision that sets every revenue line in the forecast, six hours is remarkable.

So the number you're hunting describes a relationship between your product and a specific group of people at a specific time. Treat it as a property of that relationship and the research design gets much more obvious.

Why Your Production Costs Are the Wrong Starting Point

On the music backing track app, the client came from the music world and knew exactly what the recordings had cost to produce. Studio time, session players, mixing, mastering. All of that sat in their head as the floor under the price, and they wanted it back within weeks of launch. As Simon put it at the time, that's just not how things work.

We'd recommended a low price point to drive mass adoption, because the market was niche and the content suited volume. Our advice was blunt. Nobody will actually pay what you think it should be worth, and instead we should be looking at this as purely as a volume product. The client pushed for the high price, and sales came in low. Our read then and now is that lower introductory pricing or a volume model had the better chance of producing more downloads and more total revenue.

The deeper problem with a cost anchor is that it closes off the conversation before it starts. Once a founder has decided the price has to clear production spend, a lower price isn't a test any more, it's a loss. A consumer app pays back over years through volume, retention and word of mouth, so the right mental model is a long-term investment in a product.

Write down your production cost on a separate page from your pricing work. Look at it when you're modelling payback, never when you're choosing the number on the paywall.

Sizing and Segmenting the Market Before You Pick a Number

Part of what went wrong on the music app was market size, and we'd flagged it early. The audience was niche and it split into two groups with almost nothing in common. Professional and semi-professional musicians compared the product against studio costs and sample libraries, so their reference price was high. Casual players at home compared it against a three pound app and free videos, so their reference price was close to zero.

One price for both groups satisfies neither. The professionals don't notice the saving and the casual players walk away, which is how a product with genuine quality ends up with a sales chart that looks like a flat line.

A niche market can carry a higher price, but only if you've worked out which niche you're in.

Niche positioning does support a premium when the value is communicated properly. Pricing research from Simon-Kucher & Partners puts sustainable premiums for niche products at 20 to 200 per cent above mass-market alternatives, with that last condition doing the heavy work. The premium follows the explanation, not the quality.

So before you pick a number, write down who each segment is, how many of them exist, what they currently pay for the nearest substitute, and whether you can reach them affordably. If the arithmetic on segment one looks thin, it's much better to find that out in a spreadsheet.

Research Methods That Give You a Usable Number

Good app pricing research gives you a range and a reason, and the methods stack rather than compete. Run them in sequence and each one narrows the band left by the last.

Asking about app willingness to pay

1. Audit what the nearest ten alternatives charge, including the free ones.
2. Interview fifteen to twenty target users about the last app they paid for and why.
3. Run the four Van Westendorp questions to find the range people call too cheap and too expensive.
4. Use a Gabor-Granger ladder to see how purchase intent falls as the price climbs.
5. Trade features against price so people have to give something up to save money.

Treat every answer as directional. AppTweak notes that 60 to 80 per cent of people say yes when asked whether they'd use an app, while actual usage lands nearer 10 to 20 per cent. Stated intent runs hot, and stated price runs hot with it.

Watch for insider bias too. People who know the product deeply already understand what sits behind the price, so the number feels obvious to them. A new user arriving with none of that context is pricing a very different thing, and that gap is where most internal pricing arguments come from.

Ask what someone paid for their last three app subscriptions before you ask what they'd pay for yours. Real spending history calibrates everything that follows.

Testing Price Points With Real Users

Research narrows the band and testing picks the number inside it. The useful part is that you can test price points long before the product is finished, as long as the thing you're testing involves a genuine decision with a real button at the end of it.

• Store-level price experiments across comparable regions.
• Paywall variants shown to matched cohorts at the same moment in the journey.
• A pre-launch page with a working checkout and an honest waiting list message.
• Different annual-to-monthly ratios, holding the monthly price steady.
• A holdout group kept at the original price so you can read the difference.

Where the price lives matters as much as what it says. We worked on an anonymous messaging app where registration came first, before anyone saw anything inside. That meant the App Store listing and screenshots had to carry every piece of value messaging we'd normally drip-feed through use, so there was a lot of out-of-app work to do. The price sat on that same page, read against whatever the screenshots had managed to promise.

That's the thing a split test on its own hides. A price fails for two reasons, and one of them is that the value never arrived in time to justify it. Test the explanation alongside the number, or you'll conclude people won't pay when what they wouldn't do is guess.

Choosing the Right Pricing Model for Your App

The model shapes the number, so picking one before you finalise the price saves a lot of rework. Each carries a different demand on the product and a different failure mode.

On the music app, the content sat naturally in the volume column and the client priced it as a premium one-off. The mismatch between those two things explains the sales figures better than any single price decision does.

Free trials sit across several of these and people like them. MoldStud reports that 85 per cent of businesses find value in free trials when weighing up pricing models. The thing a trial really tests is whether your product reaches its first good moment inside the window you've given it.

How Fees and Price Presentation Change the Answer

On a travel booking product, we decided early to fold the platform's Stripe booking fee into one clean total. The reasoning seemed sound, because travellers say they want a single number. What we found was the opposite. Users expected to see a platform fee as its own line, because that's what every travel app they've used does, and the absence of it made them suspect a charge was waiting further down the flow.

There's a real difference between somebody booking a holiday on a website and somebody using an app that's all about travel. The second group arrives with a mental model of how platforms present money, and designing against that model cost us trust even though the total was identical.

We showed people more information and they came away with more confidence, not less.

So we broke everything out. Every fee visible, every line labelled, nothing rolled up. Confidence went up, because people stopped wondering what the single number was hiding.

We saw the same pattern from the other direction on a marketplace checkout project. Confusion over whether a fee sat on top of the price or inside it produced hesitation and drop-off, and the amounts involved were small. Clarity was doing the work, not the size of the charge.

Reading Behavioural Signals in Live Data

Once the app is live, people answer the pricing question with their behaviour every day. The signals worth watching are the ones that sit either side of the payment moment, because that's where intent turns into a decision.

• Paywall views against purchases, split by where in the journey the paywall appeared.
• Trial starts against trial conversions, and how long people lasted before converting.
• The exact step where checkout stalls, which is often a fee line rather than the price.
• Refund and cancellation reasons, read individually rather than in aggregate.
• Renewal churn at month two, which tells you whether the value kept pace with the charge.

When you ask shapes what you learn, and this is where a lot of feedback data goes wrong. A client of ours added a rating prompt that fired the moment somebody opened the app. People hadn't had the chance to experience the value of the product yet, so the ratings described nothing at all. Prompts belong after a genuinely positive moment, once someone has achieved something inside the app.

The older pattern was worse, with prompts surfacing at the point of uninstall. By then a person either has no need for the product or has had a bad experience, so the feedback skews hard and represents almost nobody.

Put your pricing feedback prompt directly after a success moment, not after a payment. Payment is when people feel the cost, success is when they can judge the value.

Modelling Revenue From a Price Assumption

A price is only half an answer until you've modelled what it produces. On a niche trading platform we worked on, the revenue came from commission on trades rather than a flat fee, which made the forecast far more involved than multiplying users by a subscription price.

We had to build the model from the parts, and every part needed its own assumption.

1. User acquisition at the start of each month.
2. Monthly churn against that cohort.
3. Transactions per user per month across the life of their account.
4. The conversion rate from download to active, revenue-generating user.
5. Commission rates, platform fees and estimated dispute amounts.

Mapping all of that out gave us credible one, three and five year projections, which is what investors were asking for. The value of the exercise was watching which assumptions mattered. Small moves in churn and transaction frequency swamped the commission rate entirely, which told us where the product work needed to go.

Keep your conversion assumptions grounded. Userpilot puts the in-app purchase conversion benchmark for mobile apps at 2.6 to 5.5 per cent. If your model needs fifteen per cent to work, the model is the thing that needs changing.

Pricing Tactics That Cost You Trust

Simon often points back to the old days of gaming here, and the pay-to-win pattern in particular, where players simply couldn't finish a level without handing over money. That was a very clear way of getting people hooked on a product so they ended up spending. It's largely gone now, replaced by earned engagement and earned rewards, which lets people reach what they need without being squeezed.

The same logic applies to anything that manufactures pressure around a price. Countdown timers on offers that reappear tomorrow, inflated original prices with a permanent discount beside them, cancellation flows buried three screens deep. These lift a week of numbers and cost you the renewal, the review and the recommendation.

Everything we learned on the travel product points the other way. People paid more attention when we showed them more, because every visible line removed a reason to wonder what was hidden. Trust at the point of payment is built out of small clarities.

A reasonable test before shipping any pricing mechanic is whether you'd be comfortable explaining it to the user in plain words. If the sentence has to be vague for the tactic to work, the tactic is borrowing against the relationship.

Revisiting Price After Launch

Your launch price is a hypothesis with a date on it. Competitors move, your feature set grows, your audience shifts, and the reference prices in people's heads shift with all of it. A price set two years ago and never revisited is describing a product that no longer exists.

Review it on a schedule rather than in a panic. Twice a year suits most apps, with a look at churn by cohort, conversion by acquisition source and the current prices of the five nearest alternatives.

Test increases on new cohorts first, so your existing users never pay for your experiments.

When you do raise a price, protect the people who got there early. Grandfathering existing subscribers costs less than the churn and the public complaints that follow a sudden rise, and it reads as fairness rather than generosity.

Regional pricing deserves its own pass. RevenueCat notes that Apple suggests pricing subscriptions around 21 per cent lower in India and 26 per cent higher in the UK, while many apps go considerably further in both directions. One global price is leaving money in some markets and locking you out of others.

Conclusion

Finding out what people will pay for your app is a sequence rather than a single moment. You size and split the market, you research a range, you test price points with people who have a real decision in front of them, and then you keep reading the live data once money starts moving. Each stage narrows the band left by the one before it.

The two patterns that cost the most are easy to describe and hard to resist. One is anchoring the price to what the product cost to make, which is what happened on the music app and why its sales never reached what the content deserved. The other is presenting the price in a way that leaves people guessing, which is what we did on the travel product until we broke out every fee and watched confidence climb.

Get those two right and the rest is arithmetic you can check. Pick a model that matches how people actually use the thing, model it honestly, and go back to the number twice a year.

If you're working out what to charge, or your current price is producing numbers you can't explain, let's talk about your app pricing.

Frequently Asked Questions