💳 How to create pricing plans for SaaS products?

we are debating a free trial vs money back guarantee - it is less about cost, but more about which one gets someone actually to try product and see the value especially for PH launch

@adana any thoughts on it?

the dashboard is the right build, but it makes the easy half easy. toggling features per plan is reversible. the thing underneath it is not.

what locks you in is the unit you meter on. seats, projects, storage, tokens. once the price is expressed in one of those, your onboarding, your invoices and every conversation with a customer inherits it, and changing it later is a migration rather than a settings change.

how i learned it: our first paying customer signed, paid, and then never opened the thing. we had priced per seat, and seats were the part they were least sure about, so they bought the smallest number that let them say yes and never had a reason to come back. the feature split was fine. the unit was wrong.

so the question i would put ahead of what goes in each tier is, what is this customer already counting in their head before they meet you. if you meter the thing they were already counting, the plan explains itself. if you meter the thing that is cheapest for you to measure, you end up with a dashboard full of correct toggles and a churn number nobody can account for.

Not sure how useful this is, since I work alone. Development, marketing, support, all of it is me.

Because of that, when I put a product out I aim for more features than the competing products already on the market, at a lower price than them. Then switching is a rational decision for the customer rather than a favour they're doing me. The theory is simple enough that it probably reads as something that only works on paper. But working alone means I can run at close to no cost, so I can actually hold both ends of it at once. The customer gets equal or better for equal or less, and as long as I keep my own costs under control I still make money.

If you're doing this as a team, you might get to a simpler answer by designing for the lowest running cost of the organisation first. The plans tend to fall out of that, rather than the other way around.

We're in the exact same boat with Weekary — and "subject of many team meetings" is an understatement 😅

The hardest part for us wasn't the technical side (feature flags, usage limits — that part is solvable). The hard part was the philosophy question underneath: are we pricing by value delivered or by features accessed?

Early on we kept asking "what should be in the free plan?" — but that was the wrong question. The right question turned out to be: what's the moment a user realizes this is worth paying for? Price around that moment, and the plan structure follows more naturally.

A few things that helped us move forward:

AI usage was the trickiest lever. It's a real cost, so you can't just make it unlimited. But hard token caps feel punishing. We ended up thinking about it in terms of "jobs to be done" per month rather than raw token counts — it's a framing users actually understand.

Storage is easier to justify than features. Users intuitively accept "more storage = more money." But hiding features behind a paywall requires much more trust — they need to believe the feature is worth it before they can try it.

The plan nobody picks tells you something. If your middle tier is getting ignored, it's usually priced wrong or positioned wrong — not a segmentation problem.

Still iterating ourselves. What's the specific tension you're hitting — is it more about segmentation across user types, or about the AI/storage cost structure?

Initially, we knew that pricing needed to be simple and flexible to appeal to our small business audience. We did a lot of testing via interviews and real users, and we made sure to account for users in different markets (ie., someone in the US was willing to pay more than someone in Australia). We also compared to competitors and other tools that our audience uses. That was all pretty successful. More recently though, we identified new use cases for our platform – agency and enterprise buyers – and the pricing model needs to reflect that. We've introduced an enterprise plan, which is negotiable on use volumes and requirements.

Most of this thread is on the value side — what to meter, value vs. features accessed.
If you are building an AI product, one also needs to think of the the cost side (for tokens) and how that scales.

Token usage can vary a lot among users. A light user and a heavy user live in different universes on token consumption, and model choice alone (frontier vs open source) swings it ~10x.

So it's important to also pick a metering unit that tracks your actual cost variance, not just perceived value.

And keep track of the (token) benefits given off in the free tier — the subscription revenue needs to pay for that too. So you'd need to estimate what % of your userbase is on free-tier and what's their likely consumption.

I recently wrote about how I'm thinking through exactly this, sharing in case it's useful - https://www.linkedin.com/pulse/how-im-thinking-through-pricing-my-ai-saas-varun-torka-3dzic/

On the mixed room, the part I would worry about is that the invited Free user never read the pricing page. They arrive by invitation, meet a limit nobody showed them, and that limit becomes their entire first impression of the product. So the decision is less about who pays and more about which limit an invited person hits first.

We're dealing with a similar puzzle from a different angle: we're turning an AI-assisted VAPT (security testing) platform into a product for small-to-midsize companies.

Security testing has always been sold as a one-time project: scope it, quote a price, done. Turning that into SaaS-style plans is hard, because unlike storage or AI tokens, there isn't an obvious "unit" to charge by.

We've been weighing a few options: number of devices/systems covered, how often testing happens (one-time vs. ongoing), and how much human review is included vs. just automated checks.

Has anyone here priced a security or compliance product before?

Did you go usage-based, or keep something closer to the old project-pricing model but wrap it in a subscription? Trying to avoid a pricing page that scares off a small company or undercharges a bigger one.

I had a conversation about this exact problem earlier today. the product was useful, but its pricing was based on what an “average user” would need.

We have a narrow and highly specific target audience, so our usage would be lower but more complex. It made me realize that pricing based on average usage can exclude customers who get real value from the product but use it differently