Someone asked me last month what we charged our first fifty customers. I pulled up the old Stripe dashboard and winced. Our launch price was $19 a month. Eighteen months later, new customers were paying $79 for the same core product, and the early cohort was still sitting at $19 — forever, because we'd promised them lifetime lock-in.
That promise cost us roughly $14,000 in annual recurring revenue in the first year alone. It also bought us something I couldn't have priced at the time: fifty people who told us exactly what was broken, what was missing, and what they'd have paid more for. So the question of how to price a SaaS product for early adopters is never just arithmetic. It's a trade between cash now and insight that compounds later.
Get that trade wrong in either direction and you feel it for years. Here's how I now think about it, including the mistakes I made that you can skip.
Key takeaways
- Early adopters are not buying a finished product — they're buying early access, and your price should reflect the risk they're absorbing.
- Anchor your price on the value delivered, not on your costs or on what feels "safe" to charge.
- Discount early cohorts generously, but put an expiry or a cap on the discount so you don't lock in a permanent handicap.
- Grandfathering is a promise you keep. Make it narrow: a defined cohort, a defined feature set, a defined period.
- Charge something from day one. Free beta users give you opinions; paying beta users give you requirements.
Why early adopters need a different pricing approach
Early adopters occupy a strange economic position. They take on risk that later customers never face: bugs, missing integrations, a roadmap that could pivot, a company that might not exist next year. A price that ignores this is a price that either overcharges them for an unfinished product or undervalues the leverage they give you.
The mistake almost everyone makes is treating the launch price as "the real price, just lower." It isn't. It's a different product entirely.
What they're actually paying for
When someone buys a beta or early-access product, they're purchasing a bundle of things that aren't features:
- Influence. Their feedback shapes the roadmap — and they know it.
- Locked-in terms they'll likely keep when prices rise.
- Access, sometimes literally: direct Slack channels, founder calls, early API keys.
- And yes, the discount itself, which is the least interesting part.
I once bundled "a monthly call with the founder" into a $49/month early plan. Half the cohort said they'd have paid the same price for the calls alone. That told me something useful: the features weren't the value, the access was. If I'd priced only the features, I'd have anchored too low.
The cost of a free beta
Real talk: free beta users are cheap to acquire and almost worthless to consult. They have no skin in the game, so their feedback is generous, polite, and uselessly vague. "I love it, maybe add dark mode" is not a requirement. "I'm paying $49 and this missing export is blocking my weekly report" is.
In our case, converting the beta from free to paid at launch lost us about 40% of the beta list overnight. The ones who stayed were the ones who'd been nagging us about the same three gaps for weeks. Those people built the product. The ones who left had been window shopping.
Three pricing models, and which one fits early adopters
You'll see plenty of writing on flat-rate, usage-based, and per-seat models. All of them work eventually. Early on, the choice matters less than the anchoring.
| Model | Fit for early adopters | Main risk |
|---|---|---|
| Flat rate, single tier | Excellent for beta. Simple to explain, simple to grandfather, minimal support overhead. | You'll underprice heavy users and leave money on the table with light ones. |
| Per seat | Good if the product's value genuinely scales with team size. | Early adopters are often solo operators — seat pricing caps your early revenue at one. |
| Usage-based | Risky in beta. Usage is unpredictable and buggy metering destroys trust. | You can't forecast, and a customer who hits an unexpected overage in week two churns. |
My position: launch flat, migrate to usage or seats once you know the shape of real consumption. You cannot price usage you haven't measured in production yet, and early adopters will not forgive billing surprises from an unfinished product. I'll die on that hill.
How to actually find the number
You can't derive an early-adopter price from a spreadsheet. You find it by asking people, in the right way, and then charging more than you feel comfortable with.
The conversation that beats any survey
Ask prospects what they use today and what it costs them, not what they'd pay you. "What are you doing to solve this right now?" surfaces the real alternative — which is often a spreadsheet and two hours of someone's week. Then ask what that hour is worth to them. You'll get a number. It will usually be higher than the one you had in mind.
Van Westendorp-style price sensitivity questions (too cheap, cheap, expensive, too expensive) work well as a second pass, but only after you've had the conversation. Running them cold gives you four data points and no context, and I say that having done it cold and drawn confident, wrong conclusions from 22 responses.
A willingness-to-pay test on a restricted cohort
If you want a hard signal, run a genuine price test — not a fake one. Two landing pages, two prices, a waitlist for each, and a deposit or a card capture at checkout. Real payment intent is the only survey that never lies.
On a 200-visitor test across two price points — $39 and $69 — the higher price converted at about 1.3 percentage points lower but produced roughly 60% more revenue intent. That single result changed how we launched. Nobody tells you to raise your price during beta. Almost everyone should.
Grandfathering without losing the plot
The hardest part isn't the launch price — it's the promise attached to it. Early adopters will ask, directly or by implication: "Will you raise my price later?" Whatever you say, they will remember. This is where I got it wrong twice.
Lifetime lock-in is a trap
My first promise was "your price is locked forever." It felt generous and it was, catastrophically so. Any feature we added later, we had to add for that cohort at $19. If we'd had a large enough cohort, we'd have gone under.
The version that works is narrower. Grandfather a specific feature set for a defined window: "Your plan includes everything in the current product, at $49, for as long as you stay subscribed." New capabilities land in a new tier, and the early cohort can upgrade if they want them. Sound familiar? It should — it's how most mature SaaS companies hedge.
How to communicate a price rise
When we finally raised prices for new customers, we sent the old cohort an email that did three things: it said the price was changing for new customers only, it stated clearly what they'd keep, and it gave them a window to lock in a longer commitment if they preferred. Churn from that cohort was under 3% in the following quarter.
What doesn't work is a surprise. Any early adopter who discovers a price change by visiting the pricing page feels, correctly, that they were treated as a customer rather than a partner. That resentment is durable, and early adopters talk to each other.
The price is a signal, not just a number
Here's the thing nobody puts on a pricing page: your early price tells prospects what you think your product is worth. A $9/month price signals "a small utility." A $99/month price signals "a tool that replaces part of my workflow." If you're building something that's supposed to matter, an underpriced launch attracts the wrong cohort and repels the right one.
The 40% of beta users who left when we introduced a price? Most of them had been treating us as a toy. The ones who paid were the ones already building a process around us. Same product, different signal.
So price the early product as what it will become — not what it currently is — and discount only the risk they carry. The number you land on is the least interesting part of the decision. What matters is whether the people who say yes are the ones who'll still be here in two years, telling you what to build next.
