If you sell digital products, templates, courses, or a micro-SaaS tool, you've probably wondered: am I charging the right amount? Almost every indie founder I've talked to believes they're undercharging — and most are right. But the fear of raising prices and losing customers keeps them stuck at whatever price they picked on launch day.
This guide is about how to stop guessing and start testing. Specifically: how to run a safe, reversible pricing experiment that gives you real data about what your customers will pay — without risking the revenue you already have.
Why Pricing Experiments Matter at $500–$10k MRR
At $500 MRR, a 30% price increase means $150 more per month. At $5,000 MRR, it means $1,500. These aren't life-changing numbers on their own, but they compound. And price is the one lever that improves margin without increasing your workload.
Unlike adding features (which takes weeks), running a content campaign (which takes months), or reducing churn (which is structurally hard), a pricing experiment takes a few hours to set up and delivers a result within 4–8 weeks. For a solo founder, that time-to-insight ratio is unbeatable.
The challenge is that most pricing advice assumes you're a large company with a dedicated data team. "Test prices" is easy to say. Doing it safely with 50–200 sales per month is harder. That's what this guide addresses.
The Fear of Losing Customers — and Why It's Overblown
The most common objection to running a price test is: "What if people stop buying?" It's a legitimate concern. But it assumes that your current conversion rate is fragile — that it will collapse the moment you raise your price. That's rarely true.
Consider what's actually happening when someone buys your product. They've already found it (traffic), they've already decided they want it (interest), and they've already started the checkout process (intent). The question at the payment step is whether the price is below their willingness to pay. For most buyers of digital products, templates, or software, the difference between $29 and $39 is not the deciding factor.
Research on price sensitivity consistently shows that conversion rates are more elastic at low price points (e.g., $10 vs $15) and less elastic at higher ones (e.g., $97 vs $127). Most indie founders price too low because they're anchoring to competitors or to their own perceived value — not to what customers actually demonstrate willingness to pay.
A pricing experiment doesn't answer "what's the highest price I could charge?" It answers "is my revenue higher at Price A or Price B?" That's a much safer question, and one that data can actually answer.
Frequentist vs. Bayesian Testing: Why the Difference Matters for Small Sellers
Traditional A/B testing — the kind used by large tech companies — is frequentist. You set a sample size in advance, you run the test until you hit it, and then you apply a statistical significance test (usually p < 0.05). This approach works well with thousands of daily conversions, but it breaks down at low volumes.
Here's why: a frequentist test with 80% power and 5% significance level requires about 400–1,000 conversions per variant to detect a 10% difference in conversion rates. If you have 50 sales per month, that's 8–20 months of waiting. By then, your product, your market, and your competition have all changed.
Bayesian testing answers a different question: given the data collected so far, what is the probability that Price B generates more revenue than Price A? This probability updates continuously as each sale comes in. After 30–60 conversions per variant, you often have a clear signal — even without reaching the sample sizes frequentist methods require.
The tradeoff: Bayesian estimates have wider uncertainty bands at small sample sizes, and early results can be misleading. A good Bayesian pricing tool (like PricingSim) accounts for this by being conservative: it only recommends applying a test result when confidence is high, and it shows you the full probability distribution — not just the point estimate.
What Makes a Safe Pricing Experiment
A safe pricing experiment has five properties:
1. Small scope
Only a fraction of your visitors see the test price. This limits your downside if the new price converts poorly. A 50/50 split is standard, but for products with very low traffic, you might use a 70/30 split in favor of the known-good price.
2. A clear success metric
For most indie product sellers, the metric is revenue per visitor — not conversion rate alone. A price increase that drops conversion rate 10% but increases revenue per sale 40% is a win. Optimizing for conversion rate alone will push you toward the lowest possible price.
3. A minimum run time
Never call an experiment early because it looks good after a week. Early results are noisy. Most meaningful signals emerge after 3–6 weeks, depending on your traffic. Set a minimum run time before you look at results.
4. A rollback mechanism
If the test price performs worse, you need to be able to revert instantly. This means your experiment setup must not "lock in" the new price in a way that's hard to undo.
5. A downside floor
Define in advance what constitutes failure. For most solo founders, "failure" means revenue drops more than 5–10% below the current baseline. If your experiment hits this floor, stop it immediately.
How to Set Up Your First Pricing Experiment
Step 1: Gather 90 days of transaction data
Export your sales history from Stripe, Gumroad, or Shopify. You want at least 90 days of data, with transaction date, price, and quantity. This lets you estimate your current conversion rate and demand pattern.
Step 2: Calculate your current revenue per visitor
Divide your monthly revenue by your monthly visitors. This is your baseline metric. Everything gets measured against it.
Step 3: Choose a test price
Don't test more than one price at a time. Pick one candidate price, typically 20–40% above your current price. If your elasticity is near -1.0 (unit elastic), a 30% price increase with a 30% demand decrease leaves revenue flat — so your test price should be conservative enough that you expect positive revenue even if demand drops significantly.
Step 4: Create the A/B page
The test page shows your product at the new price. Half your visitors see the test, half see the control. PricingSim generates this page automatically — complete with tracking, variant assignment, and the rollback mechanism.
Step 5: Let it run
4–8 weeks, minimum. Check the confidence dashboard weekly but don't touch the experiment. The goal is data, not early optimization.
Step 6: Apply or rollback
When confidence reaches your threshold (typically 90–95%), apply the winner. If the test price underperforms your downside floor, roll back. If the test is inconclusive after 8 weeks, either run longer or accept that you need more data.
Reading Confidence Scores
A confidence score of 87% means: "given the data collected, there is an 87% probability that Price B generates higher revenue per visitor than Price A." It does not mean Price B is 87% better than Price A — it means the direction of the relationship is probably correct.
How to interpret common confidence levels:
- Below 70%: Inconclusive. Keep running.
- 70–80%: Directional signal but too uncertain to act on. Keep running.
- 80–90%: Meaningful evidence. You could apply if the experiment has been running 6+ weeks and the revenue uplift is significant.
- 90%+: Strong evidence. Apply the winner.
- 95%+: Very strong evidence. This is the "confident recommendation" threshold.
Common Mistakes in Pricing Experiments
Mistake 1: Testing during unusual periods. Don't run a pricing experiment during your biggest launch of the year, a holiday sale, or right after a major marketing push. Unusual traffic patterns pollute the results.
Mistake 2: Not excluding promo cohorts. If you've run an AppSumo deal or a promotional discount campaign, those buyers are a different segment with different price sensitivity. Exclude them from your elasticity estimates or they'll drag your demand curve down artificially.
Mistake 3: Looking at conversion rate instead of revenue. A price increase almost always lowers conversion rate. The question is whether revenue per visitor goes up. Always optimize for revenue.
Mistake 4: Running multiple tests simultaneously. If you're testing two prices at once across different channels, you'll get confused results. One test at a time.
Mistake 5: Not communicating the change. When your test succeeds and you apply the new price, tell your audience. A short email or tweet explaining why you raised prices — with an offer to lock in the old price for existing subscribers — turns a business decision into a marketing moment.
Case Example: A Notion Template Seller
Suppose you sell a Notion productivity template for $29. You have 200 monthly visitors and a 1% conversion rate — 2 sales per month, $58 revenue.
Your elasticity estimate from 6 months of data is ε = -0.9. You test $39 (34% increase). Predicted demand at -0.9 elasticity: 200 × (39/29)^(-0.9) ≈ 1.73 sales. Predicted revenue: $39 × 1.73 = $67.47. That's a 16% revenue increase.
But the 5th-percentile scenario (if elasticity is actually -1.5): 200 × (39/29)^(-1.5) ≈ 1.55 sales → $60.45. Still above your $58 baseline. The experiment passes the downside floor.
After 6 weeks, you see 1.8 sales per month at $39 → $70.20 revenue. Confidence is 92%. You apply the new price. Revenue is now $70/month instead of $58 — a 21% increase with no additional work.
Tools for Running Safe Pricing Experiments
PricingSim automates the entire workflow described above: data import, elasticity estimation, A/B page generation, confidence tracking, and one-click rollback. The free tier supports up to 3 simultaneous experiments and all major import formats.
The alternative is to do it manually: create two versions of your product page, split traffic with a Cloudflare Worker or Netlify redirect, and track conversions in a spreadsheet. This works but requires engineering and ongoing maintenance. For most solo founders, automation is worth it.