B2B SaaS Billing Models in Boilerplates 2026

TL;DR

Most SaaS boilerplates ship a basic flat-rate subscription model (monthly/annual plans, Stripe Checkout, customer portal). But B2B SaaS in 2026 increasingly demands per-seat pricing (charge by active user count), usage-based billing (charge by API calls, tokens, or records processed), or hybrid models that combine both. Very few boilerplates support this out of the box — you'll almost always need to extend the billing infrastructure. This guide explains the billing models, which boilerplates get closest to supporting them, and what you need to add.

Key Takeaways

Flat-rate subscriptions are what 95% of boilerplates ship — Stripe Products + Prices + Checkout + Customer Portal is the standard starting point
Per-seat billing requires metered usage tracking — counting active users per billing period and reporting to Stripe Meters or adjusting subscription quantities
Usage-based billing needs Stripe Meters or Polar.sh — Stripe Meter records are the modern API (replacing the old usage_records API)
Makerkit and SaasRock have the most advanced billing infrastructure — both support seat-based pricing and have Stripe webhook handling for subscription lifecycle events
Polar.sh is gaining ground for developer-focused products — GitHub Sponsors-style billing with open source monetization, simpler than Stripe for small SaaS
Lemon Squeezy handles VAT/tax globally out of the box — critical if you're selling internationally without a dedicated tax team

The Four B2B Billing Models

Before choosing a boilerplate, understand which billing model fits your product. Getting this wrong and rebuilding billing later is one of the most expensive SaaS mistakes.

1. Flat-Rate Subscription

Example: $49/month, all features included, regardless of usage or seats

The simplest model. One product, multiple price tiers (monthly/annual). Every boilerplate supports this — Stripe Checkout handles the payment flow, the Customer Portal handles plan management, and webhooks update your database when subscriptions change.

Good for: Tools with a fixed feature set where value doesn't scale with seats or usage. Personal productivity, small-team tools, individual creator tools.

Bad for: Products that get used heavily by enterprise teams — you're leaving revenue on the table. A company with 100 users on a $99/month plan is a bad deal for you.

2. Per-Seat Pricing

Example: $25/user/month, billed monthly, minimum 5 seats

The standard B2B SaaS model. Revenue scales naturally with the customer's team size. Every enterprise contract negotiation starts with seat count.

Implementation complexity: Medium. You need to:

Track the number of active users (or invited users) per workspace
Report seat count changes to Stripe (adjust subscription quantity)
Handle mid-cycle seat additions with prorations
Define "seat" precisely — invited but not-yet-active? Admin users? Read-only users?

Stripe supports this via Subscription Items with a per-unit price. When a user is added to a workspace, increment the subscription quantity; when removed, decrement it.

3. Usage-Based Billing

Example: $0.002 per API call, billed monthly in arrears

The model that aligns your revenue with the value customers get. Winning in AI products ($/1K tokens), data tools ($/record processed), and communication tools ($/SMS sent).

Implementation complexity: High. You need to:

Instrument every billable event in your application
Aggregate usage per customer per billing period
Report aggregated usage to Stripe (via Stripe Meters)
Display usage to customers in real time (so they're not surprised at billing)
Set configurable usage limits and alerts (or customers will churn on their first unexpected bill)

Stripe Meters (the 2024 replacement for the old usage records API) work like this:

// Report a billable event
await stripe.billing.meters.createEvent({
  event_name: 'api_call',
  payload: {
    value: '1',  // 1 API call
    stripe_customer_id: customer.stripeId,
  },
})

Stripe aggregates these events per billing period and charges the customer automatically.

4. Hybrid: Seat + Usage

Example: $50/seat/month base + $0.001 per API call over 10,000/month

The model that enterprise pricing teams love and engineering teams dread. Combines the predictability of seat-based pricing with usage-based upside.

Implementation complexity: High. You're running both a quantity-based subscription and a metered usage subscription simultaneously. Each requires separate Stripe Subscription Items with different price types.

Makerkit explicitly supports this pattern in its billing documentation — two subscription items (seats + usage) on the same subscription, with separate reporting flows.

What Boilerplates Actually Ship

Makerkit — Most Advanced Billing Infrastructure

Makerkit is the only major boilerplate with dedicated documentation for multiple billing models:

Flat-rate: Ships configured. Stripe Checkout, Customer Portal, webhook handlers for all lifecycle events (created, updated, canceled, payment failed).

Per-seat: Supported with configuration. Makerkit's billing service tracks member counts and can update subscription quantities via Stripe API. The boilerplate includes the seat count display in the billing dashboard.

Usage-based: Documented with Stripe Meters integration. You define billable events in Makerkit's billing config, and the service reports them to Stripe Meters. Usage is displayed in the customer billing dashboard.

Hybrid: Documented in Makerkit Pro — multiple subscription items with different price types on a single subscription.

Makerkit also supports Lemon Squeezy and Paddle as billing providers (via their plugin architecture), giving you tax/VAT handling alternatives to Stripe's Tax product.

SaasRock — Strong Multi-Tenant Billing

SaasRock's billing system is designed around multi-tenant (workspace) SaaS:

Subscription management with plan limits (max users, max storage, max records)
Plan enforcement middleware — features are gated based on the workspace's current plan
Usage dashboard — tenants can see their current usage against limits
Stripe Customer Portal integration

SaasRock doesn't support metered usage reporting (Stripe Meters) natively, but it does handle the plan limits pattern well — defining limits per plan tier and enforcing them in the application layer. This is the "soft cap" approach: instead of billing more for usage, you gate features at plan limits and require an upgrade.

ShipFast — Basic Flat-Rate Only

ShipFast ships Stripe Checkout + Customer Portal for flat-rate subscriptions. It's the simplest implementation — one webhook handler, plan check middleware, and the Stripe-hosted pages for payment and plan management.

There's no seat tracking, no usage reporting, no metered billing. If you need per-seat or usage-based billing with ShipFast, you're building it from scratch on top of the existing Stripe integration.

Supastarter — Flat-Rate with Multiple Providers

Supastarter supports Stripe and Lemon Squeezy for flat-rate subscriptions, with Paddle support documented for teams selling to European markets where VAT handling is complex.

Per-seat and usage-based billing aren't included, but the billing abstraction layer is clean enough to extend.

T3 Stack (Open Source) — Minimal Stripe

The T3 Stack's community billing additions (via the @acme/stripe package in T3 Turbo) cover flat-rate subscriptions with plan checks. It's a starting point, not a production billing system. Expect to write significant billing code on top.

Implementing Per-Seat Billing in Any Boilerplate

If your boilerplate doesn't support per-seat billing natively, here's the pattern:

Step 1: Track Seat Count

Define what a "seat" is in your data model. Most B2B SaaS bills for invited users, not just active ones (otherwise, customers optimize by removing users when not in use):

// When adding a user to workspace
async function addMemberToWorkspace(workspaceId: string, userId: string) {
  // 1. Add to database
  await db.workspaceMember.create({ workspaceId, userId, role: 'member' })

  // 2. Update Stripe subscription quantity
  const workspace = await db.workspace.findUnique({ where: { id: workspaceId } })
  const memberCount = await db.workspaceMember.count({ where: { workspaceId } })

  await stripe.subscriptionItems.update(workspace.stripeSubscriptionItemId, {
    quantity: memberCount,
    proration_behavior: 'create_prorations',
  })
}

Step 2: Handle Downgrade Enforcement

When a customer downgrades from a higher-seat plan to a lower one, you need to enforce the new limit:

// On webhook: customer.subscription.updated
async function handleSubscriptionUpdate(subscription: Stripe.Subscription) {
  const newMaxSeats = getMaxSeatsFromPrice(subscription.items.data[0].price.id)
  const workspace = await db.workspace.findUnique({
    where: { stripeSubscriptionId: subscription.id }
  })

  const currentSeats = await db.workspaceMember.count({
    where: { workspaceId: workspace.id }
  })

  if (currentSeats > newMaxSeats) {
    // Flag workspace as over-limit — prevent new logins until resolved
    await db.workspace.update({
      where: { id: workspace.id },
      data: { status: 'over_limit', maxSeats: newMaxSeats }
    })
    // Send email to workspace owner
  }
}

Step 3: Display Seat Usage

Always show customers their current seat count vs. their plan limit. Surprise billing is the #1 cause of B2B SaaS churn:

<BillingCard>
  <div className="flex justify-between">
    <span>Team Members</span>
    <span>{currentSeats} / {maxSeats} seats</span>
  </div>
  <Progress value={(currentSeats / maxSeats) * 100} />
  {currentSeats >= maxSeats && (
    <Alert>You've reached your seat limit. <a href="/billing">Upgrade to add more.</a></Alert>
  )}
</BillingCard>

Implementing Usage-Based Billing with Stripe Meters

For AI tools, API products, and data platforms, usage-based billing with Stripe Meters is the right approach:

Step 1: Create a Meter in Stripe

// Run once: create the meter in your Stripe account
const meter = await stripe.billing.meters.create({
  display_name: 'API Calls',
  event_name: 'api_call',
  default_aggregation: { formula: 'sum' },
  customer_mapping: {
    event_payload_key: 'stripe_customer_id',
    type: 'by_id',
  },
})

Step 2: Report Events on Every Billable Action

// In your API handler, after each billable operation
export async function POST(req: Request) {
  const result = await processApiCall(req)

  // Report to Stripe Meters
  await stripe.billing.meters.createEvent({
    event_name: 'api_call',
    payload: {
      value: '1',
      stripe_customer_id: req.user.stripeCustomerId,
    },
  })

  return Response.json(result)
}

Step 3: Create a Metered Price in Stripe

In the Stripe dashboard (or API), create a Price with billing_scheme: 'per_unit' and usage_type: 'metered' linked to your meter. Attach it to subscriptions as a line item.

Billing Provider Comparison for B2B SaaS

Provider	Per-Seat	Usage-Based	VAT/Tax	Pricing
Stripe	✅ Quantities	✅ Stripe Meters	✅ Stripe Tax (add-on)	2.9% + $0.30
Polar.sh	✅	⚠️ Limited	❌	5%
Lemon Squeezy	⚠️	❌	✅ Built-in	5% + $0.50
Paddle	✅	⚠️	✅ Built-in	5%
Chargebee	✅	✅	✅	Custom

For most B2B SaaS: Stripe with Stripe Tax is the most flexible. Lemon Squeezy is a strong choice if you're selling globally as a solo developer and don't want to deal with VAT registrations — they handle it as the Merchant of Record.

Recommendations by Stage

Pre-launch (0 customers): Ship flat-rate subscriptions. Don't overthink billing before you have paying customers. Makerkit or ShipFast both work fine.

Early traction (1–50 customers): Add per-seat billing if your product is used by teams. The Makerkit pattern is the cleanest to implement from a boilerplate base.

Growth (50–500 customers): Add usage alerts and limits. Consider Stripe Meters if you have meaningful usage variation between customers.

Scale (500+ customers): Hire a billing engineer. At this point, your billing infrastructure needs are specific enough that a boilerplate is the wrong tool.

Methodology

Billing patterns sourced from Stripe official documentation, Makerkit billing docs, SaasRock changelog
Pricing data from provider websites (March 2026)
Code examples tested against Stripe API v2024-12-18.acacia

Compare SaaS boilerplates by billing provider on StarterPick — filter by Stripe, Lemon Squeezy, Polar.sh, and Paddle.

Comments