The simple version
Your first pricing page reflects what you think your product is worth, not what customers will actually pay. Those two numbers are rarely the same, and the gap between them is where startups quietly bleed out.
Why founders get this wrong from the start
Picture a founder who has spent eight months building a B2B analytics tool. She knows the product cold. She’s watched competitors charge $49/month and thinks, reasonably, that her tool does more, so she prices at $79. She writes three tiers, names them Starter, Pro, and Enterprise, and ships the page. Three weeks later, she has a handful of free trial signups and no conversions.
What went wrong? She priced based on her internal model of value, which is almost entirely disconnected from the customer’s internal model of value. She thought about what inputs went into the product. Customers think about what outputs they get from it, and more specifically, what they’d lose if it disappeared.
This is the foundational error. Pricing isn’t arithmetic. It’s psychology sitting on top of economics, and if you haven’t done the fieldwork to understand how customers think about the problem you’re solving, your pricing page is just a guess with a Stripe integration.
The three things your pricing page is actually communicating
A pricing page does more than quote a number. It signals who the product is for, how mature the company is, and what the vendor thinks the customer’s problem is worth solving.
Get any one of those wrong and the math doesn’t matter. A $29/month price tag on a product pitched at CFOs will make them distrust it before they’ve read a single feature. A $2,000/month tag on a product aimed at solo freelancers will stop them cold before they’ve thought about ROI.
Tier names, anchor prices, the presence or absence of a free plan, whether you show annual pricing by default, whether you list specific features or talk about outcomes: all of it is communication, not decoration. Most first pricing pages are built by someone thinking about what looks clean in Figma, not what a prospective customer is trying to figure out in thirty seconds of evaluation.
What “wrong” actually looks like in practice
There are a few predictable failure modes.
The first is underpricing, and it’s more dangerous than it sounds. When you price too low, you attract customers who can’t pay more, which means you need more of them to survive, which means your support burden scales faster than your revenue, which means you’re always behind. You also send a signal that the product isn’t serious. Underpricing your startup is harder to fix than overpricing because raising prices on existing customers is politically and contractually painful in ways that lowering them isn’t.
The second is feature-stuffing tiers instead of value-segmenting them. Founders tend to gate arbitrary features to push users toward higher tiers, but customers don’t think in features. They think in outcomes. “Up to 5 users” is a constraint. “Advanced collaboration with audit logs” speaks to why a team would actually upgrade. The distinction seems small until you look at your upgrade rate.
The third is building the wrong number of tiers. Three tiers feels like the industry standard, and for many products it makes sense, but it’s not a law. Some products work better with two. Some enterprise products work better with just a “contact us” page and a case study deck. The tier structure should come from how your customers actually segment by willingness to pay and use case, not from what every other SaaS company does.
The fourth, and most common, is pricing in isolation. The founder sits alone or with a co-founder and reasons her way to numbers without ever asking a real buyer what they’d pay or, more usefully, what the problem costs them today if they don’t solve it.
What to do instead
The research comes before the page. Not after.
Talk to twenty prospective customers before you finalize anything. Don’t ask “what would you pay for this?” That question produces useless numbers because people instinctively lowball. Ask instead what they’re currently spending to solve this problem (software, time, headcount, outside vendors). Ask what happens to the business if the problem doesn’t get solved. Ask what a solution would need to do before they’d feel comfortable paying for it at all.
This is the framework that Patrick Campbell and the team at Price Intelligently spent years documenting: willingness to pay is best uncovered through indirect questions about value, not direct questions about price. The company was eventually acquired by Paddle, and the underlying research methodology holds up.
Run at least one pricing experiment in the first ninety days. Send different price points to different cohorts of trial users. A/B test the annual vs. monthly toggle. Try removing the lowest tier and see what happens to conversion. You need data from real purchase decisions, not opinions from user interviews.
Watch what people do, not just where they land. If most users sign up for the middle tier but the usage data looks like they need the top tier, that’s a packaging problem. If nobody touches the lowest tier, you may not need it. Month-one churners are telling you what fans never will, and the same is true of people who downgrade or never upgrade.
The honest expectation you should set
Pricing is not something you solve. It’s something you maintain. Companies with serious pricing discipline revisit it at least annually, and more often when they’re growing fast or entering new market segments.
Your first pricing page is a hypothesis. Treat it like one. Put it live, measure conversion and average contract value, talk to the customers who said no, and iterate. The founders who get this right aren’t the ones who happened to nail it on the first try. They’re the ones who built a process for being wrong quickly and correcting course before the gap between perceived value and actual pricing does permanent damage to the business.
