How to price an app: finding what users will actually pay

Pricing is the fastest lever on revenue and the one founders most often set by copying a competitor and hoping.

Pricing is the highest-leverage number in your business and the one founders most often pick by accident — glancing at a competitor, halving it "to be safe," and moving on. That instinct quietly caps revenue before the app even launches, because the price wasn't set on what the app is worth to the person paying.

Here's a more deliberate way to arrive at the number.

Price on value, not cost

The most common pricing mistake is cost-plus thinking: adding up what the app cost to build and run, then marking it up. Users don't care what it cost you to build. They care what it's worth to them — the time it saves, the money it makes, the problem it removes.

So the starting question isn't "what do I need to charge to break even?" It's "what is solving this problem worth to my target user, and what are they already spending to solve it?" A tool that saves a field-service owner two hours a day is worth far more than its hosting bill, and pricing it off cost leaves most of that value on the table.

Match the model to how you deliver value

Before the number, pick the shape. The right pricing model follows from how often your app delivers value:

• Continuous value (used regularly, benefit accrues over time) points toward a subscription — predictable, compounding revenue, but you have to keep earning it or users cancel.
• Occasional or bounded value points toward a one-time purchase or in-app purchases — simpler, but no recurring income from existing users.
• Broad-reach consumer apps often use ads with a paid ad-free tier.

Charging against the grain of your value cadence — a subscription for something used twice a year, a one-time fee for something that delivers value daily — is the structural version of mispricing. We break down each model and its trade-offs in the app pricing models guide.

Research what users will actually pay

Willingness to pay is discovered, not guessed. A few ways to learn it before you commit:

• Ask about current spending. In validation interviews, find out what your target users already pay — in money, tools, or time — to solve this problem today. That's your anchor.
• Study competitor pricing. What comparable apps charge trains your users' expectations of what this category costs. You can price above it with a reason, or below it as a wedge, but you should know the norm. This is part of a proper competitor analysis.
• Test real price points. Put different prices in front of real prospects — a landing page with a stated price and a waitlist, for instance — and measure who commits. Behavior beats survey answers.
• Run a small pre-launch offer. A pre-order or founding-member price tells you, with real money on the line, whether your number lands.

Use tiers, not a single take-it-or-leave-it price

A single price forces every prospect into a yes/no. A good-better-best structure does more work: it captures budget-conscious buyers at the low end, serves power users at the high end, and — through a well-placed middle option — anchors most people toward the tier you actually want to sell. Even a simple three-tier structure typically outperforms one flat price, because it lets different willingness-to-pay levels each find a fit.

Trials, done right

Trials reduce the risk a buyer feels by letting them experience paid value before committing. The key, whichever style you use, is that the trial has to reach your app's core value quickly — a trial that expires before the user understands what they'd be paying for converts no one.

• A standard free trial grants full access for a set period.
• A reverse trial starts a new user on the premium experience, then drops them to a limited free tier when it ends unless they upgrade. By anchoring users to the full value first, it often converts better.

Treat the price as a hypothesis

The most freeing reframe: your launch price is not permanent. It's your best current estimate, to be revised as you learn what users will actually pay. Prices can go up as you add value and prove worth; tiers can be restructured; trials can be tuned. Founders who treat the number as a one-time, irreversible decision agonize over it and then never revisit it. Treat it as testable, ship it, and let real buyers teach you where it should be.

The economics behind all of this — what a user costs you to serve and acquire, and whether the price clears that — is the subject of app COGS and unit economics. Price on value, model it against your costs, test it against real buyers, and revise. That's a pricing process. Copying a competitor and hoping is not.