Published
9 MIN READ
SaaS Pricing Models: What Each One Requires You to Build
A SaaS pricing model is the rule that ties the value delivered to what the customer pays: flat-rate subscription, per user, usage-based, freemium or tiered plans. Each one forces the product to build a different machine, and that machine needs to be in the scope before the first paying customer.
The guides available today treat the subject as a commercial decision made close to launch. In a Brazilian guide to building a SaaS updated in February 2025, the pricing model is step 6 of 8, after the minimum viable product and after design.
At Wama, when the scope calls for a logged-in area, a portal or something sold by subscription, the project stops being a website and becomes a digital product. It's the step described in the point where the website starts running the business, and billing is the part of it that most people forget to budget for.
What is a SaaS pricing model?
It's the rule that turns usage into an invoice. It defines what the product counts (account, person, event, unlocked feature), how often it charges and what changes when the customer grows or shrinks. It exists on the commercial side as a price list and on the technical side as code.
According to Stripe's guide to starting a SaaS business, published in April 2025, the goal is to tie what you charge to the product's perceived value. The sentence is short and hides the work: to count what generates value, the product needs to record that value as it happens.
That's why the choice isn't just commercial. It belongs to the batch of decisions described in the method that sets the scope before the first screen, alongside architecture, permissions and timeline.
The five models the market uses today
Stripe names eight variations in the same guide: tiered, usage-based, freemium, flat-rate, per user, per active user, custom and hybrid. A Brazilian software development consultancy, in a guide updated on July 15, 2026, condenses the market into five and sums up the criterion: it depends on how the product's value relates to usage.
Model | How it charges | When it makes sense |
|---|---|---|
Flat-rate subscription | A monthly or annual amount, regardless of usage | Similar usage across customers |
Per user | Proportional to active licenses | Collaboration and management tools |
Usage-based | Volume processed, API calls | Data and infrastructure platforms |
Freemium | A limited free tier, with a paid upgrade | A product that needs fast adoption |
Tiered | Stepped plans that combine the ones above | Small and large accounts in the same base |
None of this says what the product needs in order to support the model, and that's the missing question. On the pricing page the visitor will read, the screen shows the plan; the product delivers it.
What does each model force you to build?
Each model forces you to build a different machine inside the product. It's not an integration detail at the end of the project: it's scope, and scope has a price.
Model | What the product now needs |
|---|---|
Flat-rate subscription | One plan per account, recurring billing, a visible renewal date |
Per user | A count of active licenses, invites and removals, a rule for changes mid-cycle |
Usage-based | A record of every billable event, a total the customer can audit, a cap against surprise invoices |
Freemium | Limits enforced at authorization, a blocking screen, defined behavior on downgrade |
Tiered | Each feature tied to the plan that unlocks it, plan changes without losing data |
At Wama, a minimum viable product falls between US$ 4,000 and US$ 20,000, with a ceiling around US$ 40,000 depending on complexity, based on 50 to 100 quotes. The billing machine is one of the items that move the project within that range, an effect visible in what the first version of a product costs in Brazil.
Why is charging per user harder than it looks?
Because active licenses are a number that changes every day. Someone joins, someone leaves, someone gets invited and never accepts. The product needs to decide what counts as a billable person and at what moment that count becomes an invoice.
Then comes the change mid-cycle. If the customer adds five people on the 20th, the product charges a prorated amount, charges next month or waits for renewal. Any answer is a rule written in code, and changing your mind later costs more than deciding now.
Add the visible side: invites, removals, each person's role. It's the territory of roles and permissions seen from the interface side, and it only works when the count behind it is right.
Usage-based billing requires metering the customer can audit
Charging for usage means issuing an invoice the customer can dispute. For that, the product records each billable event the instant it happens, stores that record and adds it up in a way that returns the same number twice.
PayPro Global, a payments company for software, describes the stages of SaaS development in an answer published in November 2024 and updated in February 2025: ideation and market research, planning and design, development and testing, launch and customer success. Usage metering doesn't appear in any of them.
In practice, this means one more screen and one more risk. Customers want to see their usage before the invoice, and the product needs a cap so nobody gets a bill they didn't expect.
Freemium and tiers: the limit lives in authorization, not on the screen
Hiding a button isn't limiting a plan. In freemium and tiered plans, the limit has to apply at the layer that authorizes the action, because that's where the request arrives when nobody is looking at the interface.
The Brazilian consultancy cited above points out that a viable SaaS is born with a multi-user structure and clear permission logic. It's worth reading that alongside the price list: each feature needs to know which plan unlocks it, and each plan needs to know what happens on downgrade.
The free plan changes the product from another angle too. It fills sign-ups with people who haven't decided yet, which puts weight on the path to the first value action.
What happens when a payment fails?
The product needs a written answer. A declined card, an expired subscription and an overdue charge are normal states for any SaaS, and each one requires a product decision: notify, give a grace period, reduce access or block the account.
Stripe lists, among the common challenges for SaaS builders, managing recurring revenue and billing and balancing retention and churn. They're two names for the same invisible work: keeping billing running without turning a payment problem into a lost customer.
Anyone who leaves this for later usually discovers the gap in the first billing cycle, when there's still no process for handling the exception and someone fixes it in the database, by hand.
What needs to be written in the proposal?
The pricing model, what the product will count, how often it charges and what happens when payment fails. Without that, the billing machine becomes a new request in the middle of the project, with the design already approved.
Iugu, a Brazilian recurring billing provider, recommends on a page updated in June 2026 giving the product 24 months to reach initial traction. Billing needs to work for all 24 of those months, not just in launch month.
At Wama, whatever isn't written in the proposal is what becomes an extra cost, and revisions are unlimited within the contracted scope. Together, those two rules push the decision to before design, which is where it costs the least.
It's worth recording ownership too: who owns the code that handles billing is a contract clause, not an automatic consequence. And when the product was born in an AI builder, the checklist is in what to check in a product built with an AI builder.
Common mistakes when choosing a pricing model
Choosing after the design is done. In the eight-step Brazilian guide, the pricing model is step 6 and design is step 4. In that order, the product gets a machine that wasn't designed for it.
Copying the model of a similar product without looking at what that product built to support it.
Treating usage metering as a report. Nobody disputes an inaccurate report; an inaccurate invoice comes back as a complaint and a refund request.
Leaving the plan limit only in the interface, where any direct call goes right past it.
Expecting artificial intelligence to make the decision. At Wama, AI sped up the build, not the decision: the project's total timeline didn't change.
Frequently asked questions
What's the best pricing model for a SaaS that's just starting?
The simplest one that describes the product's value, almost always a flat-rate subscription or tiered plans. Usage-based models require auditable metering from day one, which increases the scope of the first version. Start with the model you can bill without manual work every month.
Can you change the pricing model after launch?
Yes, but it costs. Moving from licenses to usage means building metering that didn't exist and migrating contracts already signed. A model change usually requires a period where the old and new coexist, which keeps two billing rules running at the same time.
Is freemium worth it for a new product?
It is when the product needs fast adoption and the cost per free user is low. In exchange, you take on limits at authorization, a blocking screen, downgrade behavior and a large base of people who will never pay. It's a product choice, not just a marketing one.
How much does billing weigh on the product budget?
It depends on the model chosen, and that's why the decision comes first. At Wama, a minimum viable product falls between US$ 4,000 and US$ 20,000 based on 50 to 100 quotes, and the billing machine is one of the items that move the project within that range.
Do I need to build billing, or can I use an off-the-shelf service?
Payment processing and subscription management come from an off-the-shelf service, always. What nobody delivers ready-made is the part that depends on your product: what counts as usage, which plan unlocks each feature and what the application does when the subscription expires.
If you're defining your product's pricing model and want it written into the scope before design, talk to Wama and ask for a detailed proposal.
