How to Price Your SaaS Before You Have Any Users

You price a SaaS product before you have users the same way you'd price anything you've never sold before: by finding honest comparables, picking a number you're willing to be wrong about, and building in a way to correct course later. There's no formula that replaces that, no matter how many decimal points other guides put on it.

I say that having just gone through it myself, setting the first real price tiers for my own SaaS before a single paying customer existed. Almost everything I found while researching this was either a generic pricing-psychology checklist or a "benchmark" backed by a stat that had no visible source. I don't think that's useful, so this is the plainer version — what I actually weighed, in order, and what I decided to just guess at and fix later if I was wrong.

Why most pricing advice you'll find is basically fiction

Search this topic and you'll run into oddly specific numbers everywhere: median price points across "100+ companies," churn rates that dropped by exact fractions of a percent after a tier change, revenue figures attributed to anonymous "one founder." None of it is verifiable, and most of it reads like it was reverse-engineered to make a framework sound authoritative.

I'm not going to do that here. I don't have a dataset of a hundred SaaS companies, and neither does almost anyone writing about this. What I have is one product, no users yet, and a decision I had to make anyway. If that's closer to where you are too, the honest version of this is probably more useful than another chart with invented benchmarks on it.

Start with comparables, not a formula

The only genuinely solid advice I found in all my research was also the simplest: look at two or three tools that provide roughly the same value to roughly the same kind of buyer, and price near them. Not identical products — genuinely comparable value, to a similar person, solving a similar problem.

This matters more than cost-plus math or "value-based pricing" frameworks when you have zero usage data, because you have nothing to calculate value from yet. You don't know your churn, your support cost per customer, or how much time your product actually saves someone — those all take real customers to learn. But you can look at what your buyer already pays for adjacent tools, because that number already reflects what the market has trained them to expect.

So I looked at what creators and small teams already pay for adjacent categories — the tools already sitting in that budget line — rather than trying to back into a number from imagined unit economics I didn't have yet. That gave me a range to sit inside, not a precise number, which turned out to be exactly the right amount of certainty for this stage.

The tier structure I actually landed on

I went with three tiers, and the reasoning had less to do with pricing psychology and more to do with who's actually going to use the product at each stage.

A low-cost entry tier, priced closer to "not a real decision" than "a purchase to think over." This is for someone just trying the product on a real project, not evaluating it in the abstract. The point of this tier isn't margin. It's removing hesitation for the person who'd otherwise bounce off a pricing page entirely.

A middle tier priced meaningfully higher, aimed at the person who's already decided the category is worth paying for and just needs to confirm this specific tool earns the higher number. This is the tier I actually expect most serious users to land on, and I priced it like I believed that, rather than making it the "decoy" that exists only to make the top tier look reasonable.

A top tier for the buyer who needs more room — more usage, more of whatever the product's core unit is — priced with real distance from the middle tier rather than a token bump. If the gap between tiers is too small, nobody has a reason to move up. I'd rather have three tiers that mean something than five that create decision paralysis.

I skipped freemium entirely, on purpose. A free tier only makes sense if the product has some kind of viral loop where existing users bring in new ones, or if free serves as a genuine lead magnet with a clear moment where someone hits a wall and upgrades. Mine doesn't have that yet. What I have instead is a short free trial on every paid tier — long enough to get real value out of it once, not long enough to make "just staying on the free plan forever" a viable strategy. That felt like the more honest version of risk-reversal for where the product actually is right now.

What I was willing to be wrong about

I want to be direct about the parts of this I don't actually know yet, because pretending otherwise would be exactly the kind of fabricated confidence I'm trying to avoid.

I don't know if the entry tier is priced low enough to remove hesitation, or too low to attract the kind of user who's worth supporting. I don't know if the gap between the middle and top tier will actually convert people upward, or just sit there unused. I don't know if I'll need a fourth tier for a use case I haven't seen yet, or whether three is genuinely enough. All of that requires actual customers using the actual product, which is data I don't have on day one and was never going to get by staring harder at a spreadsheet.

What I decided instead was which parts of the decision I was comfortable revisiting quickly, and which I wasn't. The exact price points are things I'm fully prepared to adjust once real usage tells me something. The three-tier structure — entry, core, expanded — is something I'm less willing to redesign every few weeks, because constantly restructuring pricing is its own kind of cost: existing customers get confused, and you lose the ability to tell whether a pricing problem is really a pricing problem or just noise from changing the model too often.

When I'll actually revisit the price

Not on a schedule, and not because a blog post told me to run an A/B test in month one with zero traffic to test it on. The signals I'm actually watching for are concrete: people abandoning the pricing page without picking anything, a specific tier getting picked disproportionately more than the others, or support requests that all point at the same tier boundary being drawn in the wrong place. Any of those is a real signal. A vague feeling that I should probably charge more, with nothing backing it, isn't.

I'd rather sit at a slightly imperfect price for a few months and learn something real from it than keep re-theorizing a number that has no data behind it yet either way.

The takeaway

Pricing a SaaS before you have users isn't a math problem, and it isn't a psychology-hack problem either, whatever the more confident guides on this topic want you to believe. It's a decision made with incomplete information, the same as most early decisions in building something alone — pick honest comparables, structure your tiers around who's actually going to use each one, and be specific with yourself about which parts of the decision you're willing to revisit versus which parts you want to hold steady long enough to actually learn from.

For more on the money side of building solo, see more Finance for Builders posts.