š³ How to create pricing plans for SaaS products?
And againā¦ the pricing plan =D
Letās discuss the serious side of product growth.
At first, it seems easy: set some prices, create a few plans, and start selling your product.
But when the time actually comes, a ton of questions appear...
For us, pricing plans are also connected to the architecture of the product. We built a dashboard where we can include or exclude features, storage, and AI tokens for each plan.
But deciding what should actually be included in each plan became the subject of many team meetings.
Especially in our case, where we have a complex product with many different modules and capabilities - where users share large media files, work with AI, and collaborate in shared spaces.
And honestly, the question still remains:
How do you shape pricing plans that actually work?
What's your approach - from both the technical and business sides?
I'd love to hear how other makers have solved this.
Replies
RunEvr
@shivam_kushwaha16Ā So, do you mean a pay-as-you-go model?
But there are some other cases to consider. For example, when users collaborate in the same workspace, one might be on the Free plan while another is on the Pro plan. How would you handle a shared environment between users on different plans?
@adanaĀ Not necessarily pay as you go I was thinking more about usage based limits within each plan so shared workspaces stay simple even when users are on different plans
@adanaĀ How would you handle feature access in a shared workspace when member are on diffrent plan
RunEvr
@shivam_kushwaha16Ā One approach is to make the person who owns the shared room pay for storage and other resources.
When you create a workspace and invite collaborators, you become the host.
For a Direct Room between just two members, thereās another tactic: if Iām on the Free plan, I have certain limitations, while youāre on Pro and get all the benefits.
And here comes the āenvy engineā =D The Free user starts wanting the Pro plan too.
@adanaĀ That shared workspace approach is interesting especially with the host paying for storage How do you decide which features should stay available to free users?
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.
RunEvr
@rabnoor_sĀ Thanks for sharing your experience!
I see that just setting up the plans in the dashboard is probably the easiest part =)
Thereās another problem too - downgrades.
What happens when a Pro user stops paying? =D What do you do with everything they had access to while they were on Pro? That part can get tricky too.
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?
RunEvr
@burakurhanĀ Agreed with the idea that users must know whether they need the Pro plan or not.
For that reason, weāve decided to open almost all features to Free plan users, so they can understand if they need the advanced version.
Our attention is more about collaboration between plans - when Pro and Free users collaborate, use agents, and share media and data.
The tricky parts always start when Free and Pro users start to collaborate on the same thing in the same room.