What is the best pricing model for a SaaS product: per seat, usage-based or flat?

There is no best model, only the one that passes three tests for your product. Your system must be able to count the unit exactly from day one and show the customer the record. A bigger bill should land in a month the customer felt was a good one, so the unit tracks the value they already believe they get. And the unit should not tax the behavior that makes the product stick, which is the weakness of per-seat pricing, where inviting the whole team costs more so customers share logins. Flat per-account pricing is the simplest to buy and works when usage is naturally bounded, but it is dangerous when your cost of delivery moves with use, which is now the case for anything with an AI model in the loop, because the heaviest customer becomes the least profitable. Usage-based pricing aligns price with cost at the expense of predictability, so the common compromise is a flat plan with an included allowance and a rate above it. Whichever you choose, the unit is the least reversible pricing decision, so settle it before the build rather than after.

SaaS Pricing and Packaging: What to Decide Before You Build the Billing

Q: Should a new SaaS product offer a free trial or a free tier?

They are different products with different costs, and each needs to be designed rather than switched on. A free trial needs a decided end state: whether the account goes read-only or loses access on the last day, how long the data is kept, and whether the customer can export it, because a trial that ends with the customer's own data locked away produces support tickets and bad reviews. A free tier is a permanent cost that grows with your success at attracting people who do not pay. It is defensible when free usage costs you almost nothing and builds the habit that leads to the paid plan, and a liability when every free action has a real cost behind it, as it does for any AI feature. If you offer one, enforce hard limits through the entitlement layer, set low enough that the heaviest free user cannot hurt you. Both invite abuse, from repeated trial signups to automated accounts draining a free allowance. Asking for a card up front reduces signups and removes most of the abuse, and not asking raises both. Measure the trade by how many trial accounts become paying ones.

Q: Should we build our own billing system or use a provider like Stripe?

Rent the billing and build the metering. A billing provider such as Stripe handles card data, invoices, tax, failed-payment retries, refunds and proration when a customer changes plan mid-month, and it has spent years on edge cases you would otherwise meet in your first quarter. If you sell inside a mobile app, the app store owns the subscription and the choice is made for you. What the provider cannot know about is your account model, your entitlement layer and your metering, meaning the pipeline that records every billable event exactly once, tied to the right account, in a form you can show the customer. That pipeline is where usage-based products go wrong: a duplicated event or a silently dropped batch produces a wrong invoice that the customer finds before you do, so usage events need an idempotent key, a store the customer's usage page can read, and a periodic check that your usage record agrees with what the provider charged. Treat the provider's webhook as the source of truth for paid status, and create the billing account in your own company's name from day one.

TL;DR: Pricing looks like a marketing decision you can make at launch. It is an architecture decision, because every unit you charge for has to be counted by your software, every plan boundary has to be enforced somewhere in the code, and the shape of your accounts is set by who pays versus who uses. Settle four things before the build: the unit you charge for, the account model, an entitlement layer stored as data rather than scattered through the code, and the line between what you build and what you rent from a billing provider. Keep the prices themselves loose; they should cost nothing to change.

Almost every product brief we receive has a pricing page, and almost none say what a seat is, what happens when a customer has a heavy month, or who gets the invoice when one company buys for five locations. Those answers decide the data model, the permission system and the metering pipeline, and changing any of the three after launch is a migration of live paying accounts rather than a copy edit. This is what we settle before we build a SaaS product, ours or a client's.

Pick the unit you will charge for

The unit is the most consequential decision and the least reversible. Four shapes cover nearly every product.

Per seat. A price per named user. Easy to explain and count, and right where value grows with headcount. It also taxes the behavior you want: a customer who invites the whole team pays more, so they invite three people and share a login.

Per account, flat. One price for the company regardless of use. Simplest to buy, and the right default when usage is naturally bounded. Dangerous when your cost of delivery moves with use, because your heaviest customer becomes your least profitable one.

Usage-based. Priced on something the customer consumes: calls, documents, minutes, messages. It aligns what you charge with what it costs you to deliver, and AI has made that matter. Every lecture recorded in LectureNotes AI, one of our own products, is transcribed and summarized by models that cost money each time they run, so a plan with no limit on recordings funds its heaviest user from everyone else. Its cost is unpredictability for the buyer, hence the common compromise: a flat plan with an included allowance and a rate above it.

Per outcome. Priced on a result such as a booked appointment: persuasive to buy, hard to operate, because the outcome has to be defined so precisely that neither side can argue with the count.

Three tests apply to any of them. Your system can count the unit exactly from day one and show the customer the record. A bigger bill lands in a month the customer felt was a good one. And the unit does not grow with a customer's history rather than their success, the trap we described from the buyer's seat in outgrowing no-code: a bill that climbs while the business stays flat means a customer who is already shopping.

Who pays is not who uses

The second decision is the account model, and it costs the most to change later, because every permission check in the product is written against it.

Most business products are not one person signing up, paying and using. Someone buys for a team, the team uses it, one member administers it, and the invoice goes to a finance address nobody on the team has ever logged in from. That is an organization with members and roles. If you build a single-user model first, moving to organizations later means rewriting every query that assumed the user is the account.

Some products have three levels. VoiceDash, which we build and run, is a white-label client portal for voice AI agencies. The agency pays us and puts its own logo and domain on it; its clients log in and see their own dashboards. So there is a tenant, the tenant's customers, and users under each, and pricing has to be expressible at every level. CallGuard AI has a related shape: it won a US chain and onboarded its first branches, so the chain buys centrally, each branch sees its own calls, and limits can sit at either level.

Four questions, before anyone writes a data model. Who signs up, who pays, who administers, who uses? Can one person belong to two paying accounts? When a seat leaves, does it free up immediately or at renewal? Can a customer have customers of their own?

Entitlements are data, not code

The third decision is where plan boundaries live. The answer is one place, as data, never scattered through the product as checks on a plan name.

The failure mode is familiar. A developer gates a feature by checking the plan name inline. Six months later there are two hundred such checks, an enterprise customer wants the top features at a middle price, marketing wants a new tier, and every request is an engineering ticket.

The fix is an entitlement layer. Each account carries a set of capabilities and limits: which features are on, how many of each thing are allowed, what the included allowance is, what happens above it. Plans are named bundles of those entitlements. The product asks whether this account can do this thing, and never asks which plan it is on.

That one choice makes the expensive things cheap. Grandfathering existing customers when prices change is a new bundle for new accounts, while old accounts keep what they had. A custom enterprise deal is a bundle with different limits, not a fork. Repackaging is a change to a table rather than a deployment. And when a limit is reached, the product can say so with the upgrade path attached.

Trials and free tiers are features with a cost

A free trial needs an end state that somebody has decided. On the last day, does the account go read-only or lose access, how long is the data kept, and can the customer export it? A trial that ends in a locked account with the customer's data behind the lock is a support ticket and a bad review. A trial that ends with a clear view of what they built and what it costs to keep is a sale.

A free tier is a permanent cost that scales with your success at attracting people who do not pay. It is defensible when free usage costs you almost nothing and builds the habit that leads to the paid plan, and a liability when every free action has a real cost, as anything with an AI model in the loop does. If a free tier exists, it needs hard limits enforced by the entitlement layer, set low enough that the heaviest free user cannot hurt you.

Both invite abuse before they attract customers: repeated trials, automated accounts draining a free allowance. Asking for a card up front reduces signups and removes most of the abuse. Not asking raises both. Whichever you choose, measure how many trial accounts became paying ones and what they did in their first week that the others did not, as launching a product argues.

Build the metering, rent the billing

The last decision is what you build and what you rent, and you should build less than most teams do.

Rent the billing provider: card handling, invoices, tax, failed-payment retries, proration when a customer upgrades mid-month, refunds. A provider such as Stripe has spent years on edge cases you will meet in your first quarter. If you sell inside a mobile app, the choice is made for you: the app store owns the subscription, takes its share and tells you the outcome.

Build the three things the provider cannot know about: the account model, the entitlement layer, and the metering, the pipeline that records every billable event exactly once, tied to the right account, in a form you can show the customer.

That last part is where usage-based products go wrong. If the same event is counted twice, or a batch silently drops, the invoice is wrong and the customer finds out before you do. Usage events need an idempotent key so a retry cannot double-bill, a store the customer's own usage page can read, and a periodic check that your record of usage agrees with what the provider charged. The rules in building financial software apply the moment a number on a screen becomes a number on an invoice.

Two more rules. The provider's webhook, not your checkout page, is the source of truth for whether an account is paid, read from your own copy of it, not by asking the provider on every request. That is a small integration project: the provider owns the card and the invoice, you own the plan and the entitlements. And the billing account belongs in your company's name from day one, with your builder invited in, for the reasons in software ownership and handover.

Agencies reselling a usage-based service at a flat price also need per-customer cost visible in near real time, the point of white-label voice AI for agencies.

Questions to settle before the build

What exactly is the unit? Written down, with the counting rule and the record the customer sees.
Does our cost move with usage? Then where is the cap? Choosing an AI model is partly a pricing decision.
Who signs up, who pays, who administers, who uses? And can a customer have customers?
Where do plan limits live? If the answer is in the code, ask what changing a plan costs.
What happens on the last day of a trial? To the account, and to the data.
Can a non-engineer change a price? If not, every pricing experiment is a release.
Which usage events would double-bill a customer if they arrived twice?

The bottom line

The numbers on the pricing page are what everybody argues about, and they matter least, because a well-built system lets them change. The unit, the account model, the entitlement layer and the metering pipeline are the expensive parts, and they get decided in the first weeks of a build whether or not anyone chooses them. We build and run SaaS products of our own, from Fyuel in the fuel trade to VoiceDash for voice AI agencies, and the pattern holds: settle the structure first, keep the prices loose, and the pricing page becomes something you can rewrite on a Tuesday.

Scoping a SaaS product and not sure what to charge for? Book a demo and bring your draft pricing page. We will tell you what it commits the build to, and what should stay flexible. See our work: Fyuel, VoiceDash, LectureNotes AI and more.