For software companies, the first pricing challenge is getting to market. The second, and far more persistent, is evolving once you're live. In usage-based and hybrid pricing models, pricing isn't just a go-to-market decision. It's a product surface. And like any part of the product, it needs to evolve quickly, safely, and predictably.

The reality most teams face is frustrating: pricing changes that should take minutes end up taking months. And surprisingly, that's not a process problem, it's an architecture problem.

Most billing systems weren't built for usage-based pricing that evolves frequently. They were built for old seat-based subscriptions that change yearly. What's at the root of this mismatch? The fundamental difference between plan-based architecture and centralized rate card architecture.

In this post, we'll look at why traditional plan-based models fall short and how Metronome's centralized rate card model helps teams ship pricing updates with the same speed and control as code.

Why most billing systems start with "Plans"

The plan-based model is where most billing systems began. It reflects the traditional subscription model: define a few tiers (e.g., Good, Better, Best), assign fixed per-seat prices, and let customers subscribe.

At first glance, plans feel simple. Each one bundles a set of prices, and customers opt in. This works well when pricing is relatively stable—say, you ship new features regularly but rarely change core seat pricing. In the traditional subscription world, plans offer a clear and manageable structure.

But that simplicity becomes a liability as companies shift to hybrid or usage-based pricing.

Usage-based pricing is dynamic by design. You're constantly adjusting usage metrics, tuning volume tiers, launching region-specific SKUs, and reacting to real-time usage patterns. 

The plan model wraps pricing, packaging, and the commercial model (some systems also include customer-specific overrides) into a single object. That means even a minor change requires creating a new plan version, migrating customers, and managing a growing web of dependencies.

What started as clean and predictable quickly becomes rigid and expensive to maintain.

Why pricing agility matters more than ever

Software companies today are launching new products and evolving pricing strategies constantly. It’s no longer like the old days when customers waited for annual renewals—now, they expect instant access to the latest features and pricing as soon as they're available.

In this environment, pricing becomes part of your product lifecycle. It needs to evolve alongside your code, your user behavior, and your market.

That’s why pricing agility matters. Whether you’re fine-tuning conversion, responding to changing margins, or rolling out new capabilities, you need billing infrastructure that lets you move quickly without burdening your billing operations and engineering teams.

Let’s say you launch a new AI feature that costs 2 credits per run. If your billing system requires a full plan migration to roll that out, you’re already behind. And if fixing a pricing bug means reapplying overrides across 200 enterprise accounts, you’re not just slow—you’re fragile.

Pricing agility is now essential for:

• Tuning price–market fit
  Iterate on pricing metrics, metering rules, volume tiers, and usage caps to see what drives conversion and retention.
• Responding to margin pressure
  Adapt pricing as infrastructure costs or customer usage patterns change.
• Launching new features
  New functionality often introduces new cost dynamics and requires immediate pricing updates.
• Staying competitive
  React to the market in real time, not just once a year at renewal.

Modern teams need to experiment, iterate, and scale pricing like they do product. That requires a billing architecture designed for change—not one that fights it.

The hidden costs of the plan-based model

Let’s walk through a common scenario in a plan-based system:
You want to increase the price of H100 instance in us-west, effective September 15.

Here’s what it takes:

• Create a new plan or version with the updated rate
• End the current subscription for each customer
• Issue mid-cycle invoices for usage up to September 14
• Start the customer subscription on the new plan, starting on Sept/15
• Manually adjust the overridden pricing (discounted)  that are not carried over 
• Issue a second invoice at month-end reflecting post-change usage

This 2-customer pricing change requires 5-6 operational steps, with each migration taking several seconds to complete. For a company with 10,000 customers, a "simple" pricing update could consume hours just for the migration process itself, let alone the manual review and adjustment of discounted pricing. And that's just the surface.

Why plan-based billing fails at scale

1. Plan sprawl

Every pricing update creates a new plan version. Over time:

• Teams struggle to find the correct active version
• Pricing history fragments across dozens of versions
• Audit becomes harder, and billing errors become more common

2. The migration tax on every price update

Even minor changes require full plan migrations. And it doesn’t stop there:

• Migration time scales linearly
  If we assume updating each subscription takes 3 seconds, updating 10,000 customers takes 8+ hours—just for the migration.
• Manual override rework
  Enterprise customers often have negotiated terms. Those overrides don’t carry over automatically after migration. They have to be reapplied, one by one.

Imagine catching a pricing bug days before month-end. Finance needs it fixed immediately. But instead of a quick change, you’re waiting hours for migrations, and scrambling to reconfigure 200+ overrides before invoices go out.

3. Partial invoices and customer confusion

Mid-cycle price changes could trigger multiple invoices for the same billing period. Customers get confused. Support tickets go up. Many companies delay pricing changes just to avoid billing disruption.

4. Rigid change management‍

Plans wrap together entire pricing structures. That makes it hard to isolate or sequence changes. Suppose you want to:

• Update GPU pricing next month
• Launch a promotional discount the following month
• Roll out new regional pricing after that

In a plan-based model, you can’t stage these changes independently. You’d have to:

• Create a version for the GPU update
• Clone that to add the discount
• Clone again for regional pricing

Each plan builds on the last. If the promo gets canceled or the regional launch moves up, you have to unwind the entire stack—manually rebuilding every downstream version.

A better approach: The centralized rate card model with Metronome

To solve the limitations of pricing agility, Metronome 2.0 introduced a centralized rate card model built for fast, safe iteration. This architecture makes pricing modular, time-aware, and easy to evolve, without duplicating plans or migrating customers.

How it works

Let’s revisit the same example:
You want to increase the price of H100 instance in us-west, effective September 15.

With a rate card model:

• Add a new rate with an effective date of 9/15
• That’s it

All linked contracts can be updated instantly, depending on whether you configure them to inherit the change or not, without requiring a pricing migration. Metronome automatically applies any pre-agreed override logic for custom pricing. At month-end, customers receive a consolidated invoice with a clear breakdown of usage across each period, including before and after September 15.

Core design principles

There are a few foundational principles in Metronome’s data model architecture that make fast, safe pricing iteration possible. Instead of treating pricing as a rigid object model, the rate card approach treats it as a modular, decoupled, and time-aware data layer. That shift unlocks ultimate flexibility without sacrificing auditability or control.

Modular
Pricing and billing components are defined independently. You can update a rate without rewriting the full configuration. Base pricing and customer-specific overrides remain cleanly separated.

Centralized
All base pricing logic is managed in a single source of truth. A change made once is reflected everywhere, ensuring consistency across customers and systems.

Temporal
Each pricing element includes an effective date range. You can schedule, backdate, or layer changes without duplicating or modifying existing configurations.

Append-only
All changes are recorded as new, time-stamped entries. Nothing is overwritten, enabling a complete audit trail and full invoice reconstruction.

How the rate card model solves plan-based pain

Let’s look at how the rate card model solves the core pain points of plan-based billing:

Built for how you actually work

The rate card model isn’t just a cleaner abstraction — it makes pricing easier to evolve, test, and operate.

• Push pricing changes without bottlenecks: Launch a new SKU or update a rate without rewriting plans or coordinating mass migrations.
• Version and schedule pricing like infrastructure: Treat rates as time-aware, auditable inputs — not hardcoded logic tied to customer objects.
• No surprises on the invoice: Customers get a clean billing experience, even when prices change mid-cycle. One invoice, no confusion.
• Scale without edge cases: The same model works whether you're serving 10 customers or 1 million — no delays, no special-case logic.

Proven at scale

Metronome’s rate card model powers billing for usage-based leaders like OpenAI, Confluent, and Databricks—supporting everything from self-serve users to enterprise contracts. If you’re embracing usage-based pricing—or already living in it—it’s worth asking:

Is your billing model designed to keep up with your business velocity? Or is it slowing you down?