Build in Public
How to Test SaaS Pricing While Building in Public
Use building in public to find pricing questions, recruit relevant buyers, and turn feedback into real SaaS pricing tests instead of relying on polls.
By Uriel Bitton · 4 min read
The short answer
Building in public can improve SaaS pricing research when founders use public posts to surface objections, recruit relevant buyers, and explain pricing decisions. Treat comments and polls as qualitative signals, not proof of willingness to pay. Validate important pricing changes with customer conversations, real paid offers, or controlled experiments, then share what you learned without exposing sensitive customer data.
Building in public can help you test SaaS pricing, but public opinion is not the same as willingness to pay. Use posts to surface pricing questions, recruit relevant buyers, and explain what you are testing. Then validate important decisions with customer conversations, real paid offers, or controlled experiments. The useful loop is public signal → buyer conversation → real behavior → public learning.
Do not let a poll choose your price
A poll asking “$19 or $29?” can generate replies without telling you whether any respondent would buy. Treat public reactions as qualitative evidence: they can reveal confusing packaging, unexpected comparisons, missing value, or objections worth investigating.
Stripe’s guide to customer-based pricing recommends combining customer research with evidence about what different segments value and are willing to pay. That is a better role for building in public: use the audience to discover hypotheses and relevant people, not to outsource the pricing decision.
Use a four-step public pricing loop
1. Share the pricing decision, not just the number
Explain the underlying question. Are you deciding between per-seat and usage-based pricing? Wondering whether a feature belongs in a higher tier? Testing whether annual billing makes sense? Give readers enough context to respond to the tradeoff rather than react to a naked price.
A hypothetical post might say: “Teams use our reporting feature very differently. We are deciding whether the Pro plan should be based on seats or monthly reports. If you buy analytics software for a small team, which cost is easier for you to predict?” That gives you language and objections you can investigate next.
2. Separate relevant buyers from spectators
Record who responded. A founder who likes your pricing page may be useful for copy feedback but irrelevant to willingness to pay if they are not in the target segment. Move the most relevant respondents into short conversations and ask what they currently use, what the problem costs them, what outcome they value, and how they evaluate alternatives.
Stripe Atlas’s SaaS pricing guide makes this distinction concrete for higher-value sales: early conversations should help you understand what customers need and what the software is worth to them rather than pretending you already know the perfect price.
3. Turn the hypothesis into a real test
Once you have a specific hypothesis, test behavior. That might mean quoting a real price on sales calls, offering a paid pilot, changing packaging for new customers, or running a controlled experiment if you have enough traffic. Do not change price, features, messaging, and checkout at the same time and then attribute the result to pricing.
Stripe’s pricing-experiment guidance recommends framing a falsifiable question, changing one variable, choosing success metrics in advance, and considering sample size before drawing conclusions. For a small SaaS, the practical test may be a series of real offers rather than a statistically powered A/B test.
4. Close the loop publicly
Share what changed after the test, but only at the level that is safe and useful. For example: “We expected smaller teams to prefer per-seat pricing, but buyer conversations kept returning to predictable monthly spend, so we simplified the entry plan.” That shows learning without publishing private customer quotes, contract terms, or a live experiment that could bias future participants.
Buildside’s guide to building in public recommends sharing decisions, evidence, lessons, and next steps while screening updates for customer, contractual, commercial, and operational risk. Pricing deserves the same boundary.
Use a pricing signal ladder
When signals disagree, rank them by how close they are to real buying behavior. A practical order is: public reaction → relevant buyer conversation → accepted paid offer → repeated conversion or retention under the new price. The earlier signals help you decide what to test; the later signals help you decide what to keep.
Y Combinator’s pricing lesson frames startup pricing around the relationship between cost, price, and customer value. That is why “people said the price seemed fair” is not the finish line. You still need evidence that the target customer sees enough value to buy.
Know what not to share
Building in public does not require exposing every price test. Keep details private when disclosure could identify a customer, violate an agreement, weaken an enterprise negotiation, confuse existing customers, or contaminate a live experiment. You can often share the question now and the lesson later.
If you are testing pricing this week, publish one decision you are uncertain about and ask a bounded question that only a relevant buyer can answer. Use the replies to recruit conversations. Then test the strongest hypothesis with a real offer. The public post starts the learning loop; the purchase behavior decides whether the pricing works.
Sources
Frequently asked questions
Can I use social media polls to choose my SaaS price?
Use polls to discover language, objections, and hypotheses, not to set the final price. Respondents are not necessarily buyers, and stated preferences can differ from purchase behavior. Validate important changes with relevant customer conversations, paid offers, or controlled tests.
What should I ask publicly about SaaS pricing?
Ask about the decision behind the price rather than asking strangers to pick a number. Useful questions include which outcome matters most, which usage limit feels natural, what alternative the buyer compares you with, and what would make a higher tier worth paying for.
Should I publish my exact pricing experiments while they are running?
Not necessarily. Publicly share the problem, hypothesis, or lesson when useful, but keep live test details private if disclosure could influence participants, create customer confusion, weaken negotiations, or expose commercially sensitive information.
What is stronger evidence than pricing feedback?
Observed buyer behavior is stronger than general opinions. Relevant signals include customers accepting a paid offer, conversion under a real price, plan selection, expansion, churn, and results from a properly designed pricing experiment.
A note from Uriel Bitton
Public feedback is useful for pricing when it helps you ask better questions, not when it gives you false certainty. I would use build-in-public posts to find the right buyers, surface objections, and explain the decision—then let actual purchase behavior decide whether the price works.
Keep building with us
Get practical founder lessons and product updates in your inbox.