How do you price your app against the competition?

A founder comes to us having spent months on a spreadsheet. Every competitor listed, every price point noted, colour-coded by tier. The logic feels solid: find the middle of the market, sit there, and let the product speak for itself. The problem is that competitive pricing, used as the primary input, answers the wrong question. It tells you what others charge. It tells you almost nothing about what your users will actually pay.

The number you choose shapes how people perceive the product before they open it, and whether the economics make sense.

Pricing is one of the decisions that feels most objective and turns out to be most psychological. The number you choose shapes how people perceive the product before they open it, how quickly they abandon the checkout, and whether the economics of the whole thing eventually make sense. Get it wrong in one direction and you leave revenue on the table. Get it wrong in the other and you price the product out of the volume it needs to survive.

What follows is how we think about pricing when a founder is trying to figure out where to start, what competitors are actually telling them, and how to avoid the traps that have killed otherwise good products.

What competitive pricing actually tells you (and what it doesn't)

Looking at what competitors charge is useful, but only as a starting point and only if you read it correctly. A competitor's price tells you what they decided their market would bear. It does not tell you whether they were right, whether their cost base resembles yours, or whether their audience and your audience are the same people.

A pre-launch founder in the football industry came to us with exactly this kind of spreadsheet. He had mapped every product in the adjacent space and was visibly excited about what he had built. He was ready to price based on where the cluster sat. But when we started asking questions about prospective users, specifically why someone would switch from a specialised app they already trusted, the conversation changed. The spreadsheet had given him confidence without giving him information. The competitor prices were real, but they belonged to competitors who had already built user habits, retention, and trust. A new entrant cannot simply copy that price and inherit those conditions.

Competitive mapping is also particularly prone to survivorship bias. You see the products that are still charging. You do not see the ones that priced into the same range and disappeared.

Use competitor pricing to understand the shape of the market. Use it to spot whether the category trains users to expect a subscription, a one-off purchase, or a freemium model. Those structural signals matter. But the actual number belongs to a different conversation.

Where to start instead: what your users are willing to pay

The more reliable starting point is willingness-to-pay research with real prospective users. This means asking people, directly, what they would expect to pay for a product that does this specific thing, and then testing their behaviour when presented with actual price points, not hypothetical ones.

The challenge is that founders often resist this step. Part of the resistance is cost. Part of it is speed. But a significant part is that speaking to real users introduces the possibility that the product, or the price, or both, are wrong. A spreadsheet of competitor prices cannot contradict your assumptions. A user interview can.

What willingness-to-pay research surfaces is rarely what the founder expected. Users who say they love the concept frequently baulk at a price the founder considered modest. Users who the founder assumed were price-sensitive often accept a higher number if the value is framed correctly. These are the things you cannot know from a competitor matrix.

Run a simple Van Westendorp price sensitivity exercise with at least 20 prospective users before you fix your launch price. Ask four questions: too cheap to trust, acceptable, getting expensive, too expensive. The overlap between the last two answers gives you a usable range.

The goal is to replace assumption with data before you publish a number that is very difficult to change without signalling distress to the market.

How to benchmark when no direct competitor exists

Some products are genuinely novel, or sit in a category too niche to have obvious comparables. This is where benchmarking gets more creative, and where the discipline of looking at adjacent markets becomes essential.

We worked through exactly this problem on a niche trading platform project. No direct equivalent existed in the market, so we identified products that performed some aspects of what the platform would do, examined their subscription models and revenue, and used those as a baseline. Where a comparable product already had strong traction, we scaled our projections down significantly to reflect the reality of launching a new product into the same space. A product with established user habits and retention cannot lend its revenue figures directly to something that has neither yet.

A product with established user habits cannot lend its revenue figures to something that has neither yet.

The method here is to decompose what your product does into its component functions, find the closest proxy for each function in an existing product, and then build a composite picture. You are not looking for a single benchmark. You are triangulating from several partial ones.

It is also worth looking across category. A wellness app that includes journalling, habit tracking, and breathing exercises has comparables in each of those verticals separately, even if nothing combines them exactly. Pull the pricing data from each and see where your proposed price sits relative to the individual pieces. If you are significantly above the sum of the parts, that is a signal worth taking seriously.

When no direct competitor exists, list the three or four things your product does that users value most, find the nearest standalone product for each, and note its price. The composite of those gives you a working benchmark that is grounded in actual user behaviour rather than speculation.

Why founders anchor price to production cost

One of the most consistent pricing errors we see is anchoring to what it cost to build or produce the thing, rather than to what the market will pay for it. The logic feels intuitive: if the recordings cost this much to make, the product needs to recoup that. If the development took six months, the price should reflect that. But consumer app economics do not work this way, and pricing as though they do produces predictable failure.

On a music backing track app project, the client knew exactly what it had cost to produce the recordings. That number sat at the centre of every pricing conversation. They wanted to recoup production costs within weeks, which is simply not how consumer app revenue compounds. Revenue in this category is built over time through volume, retention, and word of mouth. A price calibrated to recover costs quickly will almost always be too high for the volume needed to sustain the product.

We told the client directly: nobody will pay what you think it should be worth, and the product needed to be treated as a volume play from the start. They disagreed, set a high price to reflect production value, and sales were low, consistent with what the research had suggested would happen. Had they adopted lower introductory pricing and focused on adoption, both downloads and total revenue would very likely have been higher.

Production cost is a business problem. Price is a market question. Conflating the two produces a number that satisfies the spreadsheet and fails the customer.

The volume trap: when a high price kills the market

There is a specific failure mode where a high price, even a defensible one, destroys the conditions the product needs to grow. This happens when the product's success depends on adoption at scale, but the price restricts it to a small audience. The two things are in direct conflict, and it is surprisingly easy not to see it until it is too late.

The music app project is the clearest example we have of this. The market spanned professional musicians and casual users. Professional musicians might accept a higher price, but there are not many of them. Casual users, the larger population, are far more price-sensitive and far more likely to abandon at checkout if the number feels out of proportion to their level of commitment. By pricing for the professional end, the client effectively excluded the volume that would have made the product commercially viable.

Garena navigated this in the opposite direction. According to Liquid & Grit, Free Fire priced its in-app purchases more than 50% lower than comparable competitor offerings, which drove significant market share gains. A lower unit price, across a much larger user base, produced better commercial outcomes than a premium price would have.

The question to ask is not "what is this worth?" but "what price allows enough people to say yes that the product reaches the volume it needs?" Those are often different numbers, and knowing which one you are chasing changes everything about the decision.

Reading the warning signs of a vanity pricing decision

Pricing decisions sometimes have less to do with the market and more to do with what the founder believes the product deserves. This is a form of vanity product thinking applied to price, and it produces the same outcome: a number that feels right to the person who built it and lands wrong with everyone else.

We saw this pattern on both a fitness and wellness app and a grassroots football product. In both cases, founders with strong personal conviction in their vision found it difficult to separate what they believed the product was worth from what the research was telling them users would pay. Early warning signs are usually visible before the price is ever set. They include dismissing user research findings as unrepresentative, returning to earlier pricing decisions that had already been reviewed, and prolonged debate about positioning rather than evidence. Both projects exhausted their budgets in design and build without reaching a fully live product. The pricing conversation was a symptom of a broader pattern, but it was a visible one.

• The founder talks more about production quality than user outcomes when explaining the price
• Competitor pricing is accepted as validation without checking whether those competitors' conditions apply
• User research findings that challenge the price point are reframed as a sampling problem
• The price has not changed through the entire development process, regardless of what research surfaced

None of these is definitive on its own. Together, they suggest the price is being set from the inside out rather than the outside in.

How to present pricing in a way users expect

Getting the price right is only part of the problem. How you display it, what surrounds it, and whether the structure matches what users expect for this category of product shapes whether they trust it enough to proceed.

On a travel app project, users expected to see a platform fee as a separate line item. The instinct to simplify and hide that fee inside a single total felt like good design, but it produced distrust. Users were not reacting to the total cost; they were reacting to the fact that the breakdown did not look the way they expected it to. They were pattern-matching to every travel platform they had used before, and something felt off. Designing against that expectation, even with good intentions, created friction that the lower cognitive load did not compensate for.

BaseKit found a related principle operating in the other direction. According to Winsome Marketing, simplifying a pricing page by reducing cognitive elements from 138 to 32 produced a 25% increase in conversion rates. The point is not that simpler is always better or that more detailed is always better. The point is that the structure should match what the user's mental model of this type of product expects to see.

Before finalising your pricing page layout, ask five prospective users to walk through it and describe what feels familiar and what feels unexpected. You are listening for the moment they say "I'd expect to see...", that sentence tells you what mental model they are bringing and whether your design is working with it or against it.

Category conventions exist because users built their expectations through repeated exposure to similar products. Working with those conventions reduces the cognitive effort of the decision. Working against them, even for good reasons, asks users to do extra work at the exact moment they are deciding whether to commit.

Conclusion

Pricing is one of those decisions that rarely gets the attention it deserves until something goes wrong. A founder who has spent a year building a product often spends a few days on the price, then wonders why the economics are not working. The number matters that much.

The consistent thread across everything we have seen is that the best pricing decisions come from understanding what users will actually pay, tested against real behaviour rather than hypothetical responses, and then presented in a way that matches what they expect from this type of product. Competitor pricing, production costs, and founder intuition are all inputs. None of them should be the answer on its own.

A lower price is not always a concession. On the music app project, it was the commercially rational choice, and the client's refusal to take it produced the outcome the evidence predicted. A higher price is not always ambition. Sometimes it is simply a product that never finds its market.

The decisions that work are the ones grounded in what the user is actually willing to do, in a real transaction, with real money, in the actual moment of commitment. Everything else is preparation for getting to that answer.

If you are working through pricing decisions on a consumer app or lifestyle product, let's talk about your pricing strategy.

Frequently Asked Questions