How to validate your pricing before you build anything

Most founders treat pricing as a post-launch problem. They build the product, ship it, and then figure out what to charge. This is backwards, and it's one of the most common reasons good products fail.

Pricing validation is not a survey. It's not asking people "would you pay $29 per month?", that question is nearly useless because people are optimistic in surveys and reluctant at checkout. Real pricing intelligence comes from observing what people actually say unprompted about money in the context of their problem.

What community discussions reveal about willingness to pay

When someone posts "I'm paying $400 per month for [Enterprise Tool] and it still can't do this basic thing", they've told you their budget and their frustration in a single sentence.

When someone posts "does anyone know a free alternative to [Paid Tool]?", they've told you price is the barrier, not the value proposition.

When someone posts "we switched from [Tool A] to [Tool B] because it was half the price for the same thing", they've shown you where the price ceiling is.

The bing.ly Ideas tool classifies all of these as Buying Signals, a specific category of community posts that reference money, budgets, switching costs, and purchasing decisions. Filtering to this category is the fastest way to run pricing research without running a survey.

Step 1: Find the baseline spend in your category

Search for your problem space and filter to Buying Signals. Look for any mention of current spend: tool names, price points, monthly costs. Build a list of what people are currently paying to solve the same problem.

This gives you your market rate, what the median customer in this category already budgets. If you price at or below it, price is unlikely to be a barrier. If you price above it, you need a clear reason why.

Step 2: Find the spending triggers

Look for posts where someone describes switching or upgrading because of a specific capability. "We upgraded to the enterprise tier when we needed X" tells you what capability justifies a price jump. "We downgraded when they removed Y" tells you what the floor of value is.

These are your pricing anchors. The free tier has to include the features that get people in the door. The paid tier has to include the capability that makes people feel the upgrade is obvious.

Step 3: Find the price sensitivity ceiling

Look for complaints about current tools being too expensive. What price point triggers outrage? What's framed as "reasonable for what it does" versus "way too much"?

In most B2B SaaS categories, the price sensitivity ceiling is around the cost of a junior employee hour per month, roughly $50 to $100 per month for solo or small team tools, scaling with team size. If community posts mostly reference competitor pricing at that level without complaint, you have your target range.

Step 4: Look for the price-free tension

Some markets have strong "this should be free" sentiment. Open source communities, developer tools, certain content categories. If your search turns up lots of posts arguing that your category of product shouldn't cost money at all, that's a signal, not that you can't charge, but that you need a particularly compelling reason to justify the charge, or a generous free tier to neutralise the objection.

Step 5: Build a pricing hypothesis before you write code

After this research, you should have a specific pricing hypothesis: a target price point, a set of features that justify it, and a set of features that belong in a free tier. Document this before you build anything. It will constrain your feature set in useful ways, if the paid tier needs to include X, then X is not optional. If the free tier needs to include Y to get people in the door, Y ships on day one.

Pricing research done before building is not optional polish. It's how you build the right product at the right tier for the right customer, before you've spent six months building the wrong one.