How to price an app: the coffee test

Whatever you were planning to charge for your app, it’s probably too little. There’s a faster way to find the right number than running combinations through a spreadsheet, and it’s this: ask yourself one question out loud: is my app worth one cup of coffee a month? If your gut says “yeah, one a month feels fair,” congratulations – that’s your $4.99 a month price point, and you just ran the coffee test.

Before we dig into why it works, here are the four key things you need to know:

• The coffee test: Decide whether your app is worth one coffee a week or one a month, and start by anchoring your price there.
• Charm pricing is real: $4.99 feels cheaper than $5 simply because the left digit changes.
• Annual pricing: Test a meaningful saving against your regular monthly price, then compare conversion, retention, and net lifetime value.
• The golden rule: Price on perceived value rather than effort, and not what your rivals charge.

Everything below is evidence for those four lines, plus the exact questions to ask real people if you’re still not sure.

Look, I’m not great at this either. I am really bad at charging more for things even when I know they are excellent. I’ve listened to expert advice, I’ve studied the psychology of pricing, and I still struggle. So if you’re having a hard time with pricing, relax – you’re not alone, and none of what follows requires you to become a different person. It just requires you to borrow other people’s psychology for an afternoon.

Useful pricing levers

Pricing can feel a bit like guesswork, but you don’t need to start from scratch. Instead, start with these six widely used levers, then see which of them your audience responds to:

Price on perceived value – not effort, and not what your rivals charge.

• Charm pricing: $4.99 can feel cheaper than $5 because that left digit changes first. You’ve seen this used in pretty much every store you’ve ever been to, so take the hint – it works.
• Bracketed pricing: Providing three useful options makes the middle one easier to choose, particularly when each tier serves a distinct customer.
• Anchoring: Showing expensive options first changes the context in which later prices are judged.
• A high-spend tier: A costly option serves customers who want more, as long as it includes a real entitlement or service and the support economics actually work.
• Social proof: A truthful “Most popular” badge reduces uncertainty by showing what other customers chose. Field experiments show the effect of social proof varies by product, so use the badge honestly and measure what impact it has.
• Decoy pricing: A deliberately less attractive option changes how people compare the remaining choices, making it a strong candidate for your next paywall test.

Charm pricing, bracketed pricing, anchoring, higher tiers, social proof, and decoys are all common starting points. None saves you from testing the actual paywall with the actual people you hope will buy – practice always beats theory!

The $125 subscription nobody bought

The most famous decoy experiment comes from Dan Ariely’s book Predictably Irrational, which is a whole book about how humans consistently behave irrationally. Ariely looked at pricing for The Economist magazine, using this pricing:

• $59 for an internet-only subscription
• $125 for a print-only subscription
• $125 for a print and internet subscription

That middle option is clearly terrible, because you might as well take the last one. In the classroom experiment Ariely describes, 100 MBA students at MIT chose between those options: 16 chose internet-only, 84 chose print and internet, and precisely 0 chose print-only.

Seems sensible, right? Well, yes, until you see what happened when he removed the useless middle option: 68 students chose internet-only, and just 32 chose print and internet. Deleting an option nobody picked dramatically changed the choices in that classroom.

(opens in a new tab)

I’ve seen the same pricing shape first hand. Years ago I led the team that created the app for MacLife magazine, and their model was simple but brilliant: you could pay $5.99 for a single issue, or pay $0.99 to subscribe for a month and get that same issue.

Sure, some folks splashed out on individual issues. But the overwhelming majority went for subscriptions – well over 80,000 subscribers, each paying a dollar a month, and each one convinced they’d beaten the system and were getting an absolute bargain.

Yes, the Economist example was a controlled experiment, but MacLife was the same pricing shape in the wild. The point is that prices are judged in context, which is why the choices around your main price matter too.

Apps and coffee

I think all geeks have a natural distrust of all these tactics, however well proven they are. They feel like tricks, and we didn’t get into building software to run tricks on people.

And so we return to the metric that has actually caught hold among developers, which is much simpler and much more honest: how much is your app worth in cups of coffee?

Coffee is a great anchor because everyone already buys it without agonizing. Right now a takeaway latte runs $5 to $7 in most of the US, comfortably more in big coastal cities, and even a plain drip coffee averages around $3.65. Nobody runs a value analysis on that purchase – they just buy the coffee, usually every day, and sometimes more than once a day. Anchoring your price against that everyday spending makes it real in a way abstract numbers can never be.

So: do you think your app is worth one coffee a week, or one a month? Say it out loud – you’ll usually get an instinctual answer straight away. One a month? Boom, that’s your $4.99 a month price point. Or maybe one a week feels right? Four $5 coffees puts you at roughly $19.99 a month.

“Humans overwhelmingly prefer small immediate rewards over larger delayed ones, even when the delayed reward is objectively better.”

If you want to add a yearly counterpart, great! They mean users lock in for longer, and also aren’t getting monthly reminders that their subscription renews. However, you should make the saving visible and treat the number as another hypothesis in your thinking – somewhere around eight months of the monthly price is a smart place to start, but you can experiment.

Let’s work through one candidate: 12 × $4.99 is $59.88, so you might start your annual pricing at about $39.99 – about eight months. That gives the subscriber four months free while also giving you the annual proceeds up front, but again the right decision depends on conversion, churn, refunds, and net lifetime value.

Some developers go bigger, offering up to six months free when going for the annual plan. And such discounts often work, because – much to every developer’s annoyance – the psychology of pricing exists here too:

• Hyperbolic discounting is the term for the fact that humans overwhelmingly prefer small immediate rewards over larger delayed ones, even when the delayed reward is objectively better. (This is why many people genuinely prefer paying $2 a week over $30 a year, because the annual saving only begins after 15 weeks.)
• Prestige pricing is the term for the fact that we’re wired to believe a $5 coffee is better than a $2 coffee. Price is a shortcut for quality, meaning that perceived value dramatically outweighs actual value, and we assume the expensive thing must be better.

The grim flip side of prestige pricing is that it cuts both ways: price your app at 99 cents and a chunk of your potential customers will conclude it can’t be very good.

Price on perceived value, not effort

I know it’s sorely tempting to skip all this, look at what your competitors charge, and copy them, but please don’t – you really need to stop and spend time thinking about the perceived value of what you’ve built instead.

How important is that? When I asked the team at RevenueCat what the biggest thing indie developers get wrong about pricing is, it was literally the first thing they said: “Price on perceived value, not effort or what rivals charge.”

That’s a bit brief, but Rik Haandrikman from RevenueCat was kind enough to really break it down. Here are his suggested steps:

• Think of price as a hypothesis about value.
• Start by interviewing prospective users: what problem does your app solve, what do they pay to solve it today, what outcome matters most?
• Back that up with lightweight research: a Van Westendorp survey asks four questions (too cheap, bargain, expensive, too expensive) and plots a “price diamond” that shows an acceptable range.
• You’ll emerge with an approximately band such as $3–$7 a month. The easiest approach is to launch in the sensible middle of that band, keep a close eye on your trial-to-paid and 60-day retention, then nudge the price up or down in small, measured experiments. (If you want to leave early subscribers on their original tier, you can create new subscriptions and hide the others.)
• If a modest price rise barely dents your conversion rate, it means your ceiling was higher than you originally thought. If a tiny discount spikes both uptake and revenue, you were over the line. Both are possible, and both are okay – after all, you have to start somewhere, and the point is that you’re watching the numbers and making careful course corrections.

I don’t know about you, but I had to Google the Van Westendorp survey! It’s actually pretty simple, because you just ask users exactly four questions about your pricing:

1. What price is so low that you would consider the product to be poor quality?
2. What price would you consider to be a bargain?
3. What price would be so high that you would still consider the product, but would need to take some time to think about it?
4. What price is so high that you wouldn’t even consider the product?

Those four questions span a specific range – too cheap, a bargain, a bit expensive, and too expensive – and when you ask a group of people the same questions and plot the results, you get the price diamond Rik mentioned: a band of prices that can work for you.

(opens in a new tab)

From there his advice is simple but practical: start in the middle, then nudge up and down and watch what happens.

But the most important piece of Rik’s advice comes right at the start, and it’s worth reading more than once: think of price as a hypothesis about value. The coffee test gives you the hypothesis, but real users confirm or refute it. You’re not carving a number into stone that you must stick with forever – you’re making a careful guess and then testing it, which is a workflow every developer already understands.

By the way, competitor prices aren’t useless. Instead, they are part of the larger context you’re considering. Tools like Appfigures and Sensor Tower will show you what similar apps charge, and Kickstart tracks your competitors right on your Mac. Just remember what that data is for: it tells you what the market currently tolerates, not what your app is worth.

And once you have the number, how you present it matters enormously – but that’s a whole post of its own. (The short version: stop shipping the world’s most polite tip jar.)

Stop reading, start doing

1. Run the coffee test right now, out loud: is your app worth one coffee a week, or one a month? Write down the number your gut gives you.
2. Calculate annual prices at 6×, 8×, and 10× monthly, then write down the discount and net proceeds for each – pick one to test rather than treating any fixed multiplier as a law.
3. Send the four Van Westendorp questions to 20 prospective users this week, then plot the answers.
4. Try launching in the middle of the band, then watch trial-to-paid and retention before nudging.

If you’re watching your sales and listening to feedback, you’ll eventually find the sweet spot where a few users think it’s a bit cheap, a few think it’s a bit expensive, and the majority are happy.

I’ll leave the last word to Christian Selig from Pixel Pals, because I think he nails it: “A small number users complaining about your app’s monetization strategy is terrific, because if no one was complaining it means your prices are comically low and you’re being taken out to lunch.”

Raise your prices – someone should be complaining.