Skip to main content
BlogSaaS Building

SaaS Pricing Models in 2026: Per-Seat, Usage, Hybrid, and Credits

An honest comparison of the four dominant SaaS pricing models, when each one earns its keep, and the migration path most teams will take this year.

SaaS Pricing Models in 2026: Per-Seat, Usage, Hybrid, and Credits

The SaaS pricing decision that ages worst is "we will figure it out in 6 months". Six months in, you have churn data colored by a pricing model you no longer believe in, customers you cannot raise prices on, and a roadmap calibrated to the wrong metric. The four dominant SaaS pricing models 2026 are per-seat, usage-based, hybrid, and credits. Each of them ships a different product, recruits different customers, and breaks differently when AI features land. Here is the comparison and the migration paths most teams will take this year.

We run pricing on Carriva (per-seat with usage caps), the lesson-planning monorepo (hybrid: tier + monthly generations), and have evaluated all four in detail. The right model depends on what your product actually does and on your customer's mental model of "value". On the ops side, we keep hosting off managed PaaS pricing entirely — our Coolify vs Dokku vs CapRover comparison explains the self-hosted stack that makes hybrid unit economics work at solo-founder scale.

What each model is, briefly

Per-seat (per-user): customers pay per active user per month. Slack, Notion, most B2B SaaS still default here. Predictable, simple to bill, well-understood.

Usage-based: customers pay for what they consume. AWS, Stripe, Twilio. Aligns price with value but creates anxiety about the bill.

Hybrid: a base subscription that includes a usage allotment, plus overage fees. The pattern most modern SaaS land on.

Credits: a prepaid balance that drains as the customer uses different features. OpenAI API, ChatGPT Pro for some features, many AI-first apps.

These are not mutually exclusive. Most successful SaaS in 2026 are running some flavor of hybrid even when they call it "tiered" or "fair-use".

The decision framework

Three questions decide which model fits your product:

  1. Is the value scaled by users or by usage?
  2. Can the customer predict their usage in advance?
  3. What does the buyer's procurement process expect?

The combinations:

Value driverUsage predictableBuyer expectsModel
UsersYesPer-seatPer-seat
UsageYesTier with overageHybrid
UsageNoPay-as-you-goUsage-based
Mixed AI featuresNoFamiliar SaaS feelHybrid + credits

For most B2B SaaS in 2026, the answer is hybrid with a usage allotment. The era of pure per-seat is fading because AI features have variable costs that per-seat does not capture.

Per-seat: still the default for traditional SaaS

Per-seat pricing is the default if your product's value is "having a seat for each team member". Slack, Linear, Notion, Figma. The cost to serve scales roughly with active users, the value scales with active users, the buyer's mental model matches.

The economics:

  • Predictable for both sides. The buyer's CFO can plan the line item.
  • Easy to bill. Stripe Subscriptions handles it without extra logic.
  • Forces growth on usage. Customers economize on seats. You see seat counts dip in slow quarters.

Per-seat breaks when:

  • A small number of power users drive most of the value (and consume most of the cost). The seat-light customer with 100 dormant accounts pays the same as the customer with 100 active power users.
  • AI features land. Inference cost per query is real. A per-seat plan that includes "unlimited AI queries" is unsustainable economics.

Most pure per-seat SaaS in 2026 has either added a usage cap on AI features or started migrating toward hybrid.

Usage-based: the AWS model

Customers pay per unit of consumption. API call, GB stored, message sent, embedding computed.

The economics:

  • Aligned with cost. You charge what they cost you to serve, plus margin. Beautiful in spreadsheets.
  • Hard for buyers. Procurement hates "I do not know my bill next month".
  • Rewards efficiency on the customer side. Bad if the product's value is "use it a lot".

Pure usage-based works for infrastructure (AWS, Cloudflare, Stripe) where the customer is sophisticated and used to managing variable cost. It rarely works for human-facing applications where the customer is a marketing manager or a teacher.

We do not run pure usage on any of our products. The buyers we serve (CGP cabinets for Carriva, teachers for the lesson-planning apps) want predictability.

Hybrid: where most modern SaaS lives

Hybrid pricing is "subscription tier with included allotment, plus pay-as-you-go for overage". Examples:

  • Twilio: monthly usage credit included in the platform fee, plus per-message charges beyond.
  • Vercel: per-team plan with included build minutes and bandwidth, plus overages. If you self-host instead, our Next.js 15 standalone Docker guide covers the production Dockerfile we run on five apps.
  • Linear: per-seat with usage caps on certain features.

This is the pricing model that survived the AI inflection. Why:

  • Predictable for the customer in normal usage. They pay the tier price and stop thinking about it.
  • Captures value from heavy users. The overage pricing means the 5% of customers driving 30% of usage pay proportionally more.
  • Lets you ship AI features without bankruptcy. The included allotment caps your cost exposure on free-tier users and casual customers.

We use hybrid on the lesson-planning monorepo. A monthly tier (Free, Plus, Pro) includes a number of lesson generations. Overage charges per generation past the cap. The result is that the median user has a predictable bill and the heavy user pays for what they use.

The trick is calibrating the included allotment. Too generous and you eat margin on heavy users. Too stingy and you frustrate normal users into churning. We rebalance ours every quarter based on actual usage distributions.

Credits: the AI-native pattern

Credits are a prepaid balance that drains as the customer uses features. ChatGPT Pro now sells some features as credits. Anthropic, OpenAI, and Replicate sell API access in credit-like patterns. Notion AI is on credits. Cursor moved to credits.

The economics:

  • Decouples features from cost. A complex query costs more credits than a simple one. Customers self-throttle.
  • Buyer-friendly for variable workloads. They can buy a chunk and use it as fits.
  • Operationally complex. Credit balances, expiration policies, top-up flows, refund policies. Each is a small project.

Credits are increasingly the right answer for AI features specifically. The cost of an LLM call varies wildly (a 200-token prompt vs a 50,000-token prompt). Credits let you price each as a multiple of token cost.

The drawback: customer anxiety. "How many credits will this cost?" is a question we hear all the time on AI products. Surfacing the cost transparently is part of the product experience.

How AI features broke pure per-seat pricing

A short detour because this matters.

In 2023, "AI feature included in your plan" was a marketing line. By 2024, the math caught up. A typical AI-augmented SaaS query costs the vendor 0.5 to 5 cents in inference. A user running 1000 queries a month costs the vendor 5 to 50 USD. If their plan is 30 USD per month, the math collapses.

Three responses we have observed:

  1. Add usage caps inside the per-seat plan. "Pro plan includes 1000 AI queries per month, then overage." This is hybrid in disguise.
  2. Move AI features to credits. "Your plan is per-seat, but AI features cost credits."
  3. Move the whole pricing to hybrid. Reset the model.

The right response depends on how central AI is to the product. If AI is the core, credits or hybrid make sense. If AI is one feature among many, hybrid with a usage cap is cleaner.

We covered the specific question of pricing AI features for SMB in another piece because the SMB buyer (our typical customer) reacts differently from enterprise to AI-feature pricing.

The migration paths most teams take

A common trajectory we see:

  1. Year 1: per-seat or flat-tier subscription. Easy to launch. Easy to bill.
  2. Year 2: introduce usage caps inside existing tiers. Customers hit them, signal demand for more.
  3. Year 3: launch overage pricing or credits. Heavy users pay proportionally.
  4. Year 4: rationalize the model. Some teams move fully to hybrid. Some adopt credits for AI features specifically.

The pain in this trajectory is in step 3. Existing customers grandfather. New customers see the new pricing. Sales has to explain why the old customer pays differently. The longer you wait to introduce variable pricing, the more grandfathering pain you accumulate.

The contrarian take: launch with hybrid from day one. Make the included allotment generous enough that nobody hits it for the first 6 months. Then, when product-market fit is found, you have the variable lever already in place.

Pricing is not a number. It is a contract for how the customer thinks about value and cost. Pick a contract that survives the products you have not built yet.

The billing infrastructure reality

A practical concern. Each pricing model has a different operational cost:

  • Per-seat: Stripe Subscriptions handles it natively. One day of dev work.
  • Usage-based: Stripe Metered Subscriptions or your own accumulator. One to two weeks of dev work.
  • Hybrid: Stripe Subscriptions plus metered usage records. Two to four weeks of dev work.
  • Credits: a custom credit balance, top-up flows, expiration logic. Four to eight weeks of dev work, plus ongoing maintenance.

If you are picking a pricing model, account for the engineering cost. Credits are technically the most complex; we have had teams spend two months on credit infrastructure that should have been one feature shipped.

We use Stripe across all our products. The metered-billing API handles hybrid cleanly enough that we have not needed to build credits ourselves. If we did, it would be a multi-week project.

What goes on the landing page

Tactical: how you present pricing on a landing page is at least as important as the underlying model.

Three rules we follow:

  1. Show the price. Hidden pricing screams enterprise sales. Mid-market SMB buyers leave the page.
  2. Compare tiers honestly. Do not pretend the basic tier is generous if it is not.
  3. Anchor on the realistic use case. Show a plausible monthly bill for the customer you actually want.

For B2B SaaS specifically, the landing page patterns for pricing presentation are tightly coupled with the rest of the page structure. We covered the bigger picture in our B2B SaaS landing page patterns writeup.

The market positioning angle

Pricing is also positioning. A 5 EUR/month plan signals consumer or solo. A 500 EUR/month plan signals SMB. A 5,000 EUR/month plan signals enterprise. Customers self-select by price.

If you are competing in a saturated category, pricing can be your wedge. We discussed the broader strategy in our niche SaaS in saturated markets piece. Sometimes the right answer is not "build the same product cheaper" but "build the underserved 10% with a price they cannot ignore".

Common mistakes we have made

A few:

  • Underpricing the entry tier. "Free trial then 9 EUR/mo" attracts customers who never pay enough to be profitable. Raise the floor.
  • Too many tiers. Three is right. Five confuses. Two often misses the middle.
  • Hiding the overage cost. Customers assume the worst when overage pricing is buried. Surface it cleanly or remove it.
  • Pricing in the wrong currency. EU customers price in EUR; US in USD. The conversion math at checkout is not seamless. We learned this on PrepareMesCours when we had EUR-only pricing on a global landing page.

What we would test first

If you are setting pricing for a new SaaS in 2026:

  1. Talk to 10 customers about price before you pick. Not what they would pay; what they pay for similar tools today.
  2. Default to hybrid: tier with allotment plus overage. Easier to upgrade-by-removing-allotment-cap than to introduce variable later.
  3. Price the entry tier higher than your gut suggests. Cheap customers churn fast and complain loud.
  4. Make AI features a separate line. Even on hybrid, if AI is variable, surface it.
  5. Re-examine pricing every 6 months. Customers do not. You have to.

A pricing model is a long-term commitment. Like an engineering decision, it ages well or rots fast depending on whether you picked it for your real situation or for a fashionable trend.

TL;DR

Per-seat is the right default for human-collaboration SaaS without heavy AI cost. Usage-based works for infrastructure. Hybrid is where most modern SaaS pricing models 2026 lands, and where new products should probably start. Credits are for AI-native products with variable per-query cost. Pick by your value driver and your buyer's mental model. Plan for migration before you launch.

A small thing

Want to work with us?

We are a small studio shipping focused B2B SaaS for niche professional verticals. If your problem looks like one of ours, we would love to chat.