Choosing a Pricing Model for Your SaaS

Most founders agonize over the number. Should the plan be $29 or $39 a month? Should the top tier be $199 or $249? Those questions matter, but they come second. The bigger decision is the shape of your pricing — what you charge for, how customers move between plans, and how revenue grows as a customer gets more value. Choosing between SaaS pricing models is a product decision as much as a finance decision, and it quietly shapes everything from your onboarding flow to your database schema to the kind of customers who sign up.

This guide walks through the common models in plain English, how to pick a value metric that fits your product, what each model demands from the software itself, and how to avoid locking yourself into a structure you will regret in two years. It is written for business owners and operators building a SaaS product — whether that is a first product, an internal tool you are turning into a business, or a service company productizing what it already does well.

Why the model matters more than the price

A price is a number you can change next week. A pricing model is a set of promises baked into your contracts, your billing system, your marketing site, and your customers' expectations. If you charge per user and later decide to charge per location, every existing customer has to be migrated, re-explained, and sometimes re-sold. If you launch with unlimited usage and later need to cap it because costs are climbing, you will be taking something away — always harder than adding something.

The model also decides how your revenue grows. Under a flat monthly fee, a customer who triples their use of your product pays the same as they did on day one. Under a usage-based or per-seat model, revenue expands as they expand. That difference compounds over years and is often the gap between a SaaS business that grows steadily from its existing customers and one that has to keep finding new ones just to stand still.

Finally, the model is a signal. It tells prospects who the product is for and how you think about value. Per-seat pricing says "this is a team tool." Usage pricing says "you pay for what you consume." A single flat price says "keep it simple." Each message attracts a different buyer.

The main SaaS pricing models, in plain English

There are only a handful of core SaaS pricing models. Most real products combine two or three of them, but it helps to understand each one on its own first.

• Flat-rate pricing — one product, one price, everything included. Easy to explain and easy to bill. The downside is that small customers may find it too expensive and large customers get a bargain.
• Tiered pricing — usually three or four plans (for example, Starter, Growth, Pro) with more features or higher limits at each step. This is the most common structure because it lets you serve several customer sizes without custom quotes.
• Per-user (per-seat) pricing — the customer pays for each person with a login. Predictable and familiar for team software, but it can discourage customers from inviting colleagues, which can hurt adoption.
• Usage-based pricing — the customer pays for consumption: API calls, messages sent, documents processed, gigabytes stored. Revenue tracks value closely, but bills are less predictable, which some buyers dislike.
• Hybrid pricing — a base subscription that includes a certain amount of usage, plus overage or add-ons beyond it. This is increasingly the default for products with real per-use costs, including anything built on AI models.

Around these core models sit acquisition tactics — freemium, free trials, annual discounts — which we will come back to. They are not pricing models on their own; they are ways of getting people into one.

Start with your value metric

The single most useful question in SaaS pricing is: what unit of my product best tracks the value a customer gets? That unit is your value metric. For a scheduling tool it might be the number of staff being scheduled. For an invoicing product it might be invoices sent. For a property management platform it might be units under management. For a field-service app it might be technicians or trucks.

A good value metric has three qualities:

• It grows as the customer gets more value. A customer managing 200 units is getting more out of the product than one managing 20, so it is fair that they pay more.
• The customer understands it and can predict it. If a buyer cannot estimate next month's bill, they will hesitate to commit. "Per location" is easy to forecast; "per compute minute" usually is not.
• You can measure it reliably. If the metric requires guesswork, manual counts, or arguments at renewal time, it will cost you more than it earns.

Once you have a value metric, the choice of model often falls out naturally. If value tracks people, per-seat or tiers by team size make sense. If value tracks activity, usage-based or hybrid pricing fits. If value is roughly the same for everyone in your niche, flat-rate may genuinely be the right answer.

How your pricing model shapes the software

This is the part that rarely makes it into pricing articles, and it is where we spend a lot of time with clients. Every pricing model has engineering consequences. Choosing one is also choosing what your product has to track, enforce, and report.

• Tiers require entitlements. Your application needs a clean way to know which features and limits each account has, and to change them instantly when a customer upgrades. Hard-coding plan names into feature checks is the classic shortcut that becomes painful the first time you rename or restructure a plan.
• Per-seat pricing requires seat management. Invitations, deactivations, prorated charges when someone is added mid-cycle, and clear rules about what counts as a seat (do guest users count? read-only users?).
• Usage pricing requires metering. You need accurate, tamper-resistant event tracking, a way to aggregate it per billing period, and in-app visibility so customers are never surprised by a bill. Without that visibility, usage pricing generates support tickets and churn.
• Hybrid pricing requires all of the above, plus logic for included allowances, overages, and sometimes alerts or hard caps.

Billing platforms such as Stripe handle a great deal of the payment and invoicing side, and we generally recommend using one rather than building billing from scratch. But the billing platform only knows what your application tells it. The entitlement logic, the metering, and the upgrade and downgrade flows live in your product. Designing them well from the start — as a flexible layer rather than scattered checks — is what lets you change pricing later without a rewrite. It is a core part of how we approach custom SaaS builds.

Freemium, free trial, or neither

Once you know your model, you need to decide how people try it. There are three broad options, and each suits a different kind of product.

Freemium offers a permanently free plan with limits. It works when the product is simple enough to adopt without help, when free users cost you very little to serve, and when a meaningful share of them naturally grow into paid needs. It works poorly for niche B2B products with a small total market, because you can end up supporting a large free user base that will never convert.

A free trial gives full or near-full access for a limited period, often 14 or 30 days. It suits products whose value becomes obvious once someone sets them up properly. The risk is that busy buyers start a trial, never finish setup, and the clock runs out before they see value — so a trial lives or dies by its onboarding.

Demo-led sales, with no self-serve trial at all, is often right for higher-priced, more complex products where configuration, data migration, or training is part of getting started. Many vertical B2B tools do best here, at least early on, because a conversation with a real buyer teaches you more about pricing than any dashboard.

Match the model to your customer

The right structure depends heavily on who is buying. A few patterns hold up across most markets:

• Small businesses generally prefer predictable monthly costs and simple plans. Tiered pricing with clear limits, or a flat rate, tends to land better than metered billing they cannot forecast.
• Mid-size companies often accept per-seat or per-location pricing because it maps to how they budget. They also care about annual contracts, invoicing options, and the ability to add capacity without renegotiating.
• Technical buyers and developers are comfortable with usage-based pricing, as long as it is transparent and they can see consumption in real time.
• Vertical markets — trades, clinics, property managers, logistics — often have a natural unit that everyone in the industry already thinks in. Pricing by that unit makes your offer feel tailored rather than generic. Our industry work is full of examples where the right unit was obvious once we asked operators how they measure their own business.

If you sell to more than one of these groups, tiers usually bridge them: a simple self-serve plan for smaller customers, and a "contact us" tier for larger accounts that need custom terms.

Common pricing mistakes to avoid

We see the same handful of problems again and again when businesses bring us a SaaS product that has outgrown its first pricing page:

• Too many plans. Five or six tiers with subtle differences create decision paralysis. Three is usually enough, with an enterprise or custom option on top if needed.
• Pricing on cost instead of value. Your hosting bill is a floor, not a guide. Customers pay for the problem you solve.
• Gating the wrong features. Holding back the core feature that demonstrates value makes the low tier feel useless. Gate advanced, scale-related, or admin features instead.
• Ignoring variable costs. Products built on AI models, messaging, or heavy data processing have real per-use costs. Unlimited plans on top of those costs can turn your best customers into your least profitable ones.
• Building billing logic you cannot change. When plans are baked into code, every pricing experiment becomes a development project.

Test, learn, and plan for change

Your first pricing model will not be your last. That is normal. The goal at launch is a structure that is good enough to sell, simple enough to explain, and flexible enough to evolve. A few habits make evolution far less painful:

• Talk to customers about value before you talk about price. Ask what they would measure success by, and what they currently pay to solve the problem another way.
• Track how accounts actually use the product — which limits they hit, which features they never touch — so pricing decisions are based on behavior, not guesses.
• When you change prices, decide in advance how to treat existing customers. Honoring old pricing for a period, or grandfathering loyal accounts, protects trust.
• Keep plan definitions in configuration, not code, so a pricing change is a settings update instead of a release.

Building a SaaS whose pricing can grow with it

Choosing among SaaS pricing models comes down to a short sequence: find the value metric your customers already understand, pick the core model that tracks it, design a small set of tiers around real customer sizes, and build the product so that entitlements, metering, and billing can change without a rewrite. Get those foundations right and pricing becomes something you can tune as you learn, rather than a decision you are stuck with.

At Vadimages we build SaaS products and customer portals for businesses across the Portland and Southwest Washington area and throughout the US, with pricing and billing architecture treated as part of the product from day one. Our process runs from discovery through a milestone-based scope, build with weekly demos, and launch with ongoing support — you can read how that works on our process page and browse examples in our case studies. Projects start at $5,000, with fixed-scope and retainer options laid out on our pricing page. If you are planning a SaaS product and want a second opinion on how to price and build it, get in touch and we will walk through it with you.