Every week I talk to a SaaS company that wants to move to hybrid pricing (or has already started and found some issues with how to stack it).

The decision has been made and what they want is the implementation, so this is the guide I give them on Solvimon

It answers how to figure out if hybrid pricing is the right call, how to design the charge structure, how to build the metering layer, how to migrate the existing base without churning the accounts that matter. And what gotchas to look out for, because there are several!

When hybrid pricing makes sense (and when it doesn't)

The clearest diagnostic I know is to map your product on two axes.

The first is attribution, whether you can tie what your product does to a business outcome the customer measures. The second is autonomy, whether the product runs on its own or needs a human in the loop to deliver value.

Hybrid pricing fits the bottom-right quadrant, so high attribution means you can point at value clearly enough to charge for it variably.

Low-to-mid autonomy means the customer relationship still has a subscription logic to it. Clay charges a base fee plus credits. Cursor charges per seat plus AI usage. Figma does seats plus rendering credits. These aren't arbitrary decisions. They reflect what the product does and what customers can forecast.

Where hybrid doesn't fit: if your product delivers binary value, pure subscription is cleaner. If value delivery is fully autonomous and cleanly attributable to a measurable outcome, you should probably be charging on the outcome and not hiding behind a subscription base.

Hybrid as a permanent destination is fine, but hybrid as cover for not doing the harder outcome-pricing work is a mistake you'll pay for - so might as well begin to think about that.

The diagnostic question for your own product: what would happen to your revenue if your top 20% of customers used the product 3x more? If the answer you come up with is "nothing, they're on a flat fee", time to rethink that.

Designing the base fee and usage structure nicely

Most companies design the base fee wrong. They pick a round number that felt comfortable in a sales conversation, not a number grounded in value delivery.

The base fee is the cost of the relationship, not the cost of the product

Before a customer uses anything, you're providing access, support, integrations, compliance infrastructure, and the assurance that the platform is on. That has a cost. Your base fee should sit at or above that cost floor, and it should represent real value the customer would pay for even if they ran zero units through it.

For a payments platform, that's compliance overhead plus access to the integration layer. For an AI SaaS product, it might be access plus an included usage allocation. The right question to evaluate: would a customer who runs 0 transactions still renew?

If yes, the base fee is probably right. If not, you don't have a base fee. You have a setup fee.

The variable component should capture 20-50% of the customer's accepted value of one unit

In discovery, I ask customers what one unit of value (one API call, one transaction, one document processed) is worth to them, not to me. Then I price the variable component at 20-50% of that number. If a document review costs a paralegal $80, charge $15-40 per document and leave the rest as value in the customer's pocket. This is the range where deals close and customers don't feel robbed.

Here's an example to think about:

A fintech platform processing $50M/month in transactions, previously on a $3,000/month flat subscription.

Under a hybrid model: $1,500/month base fee + €0.03 per $100 processed. At $50M/month, that's $1,500 base + $1,500 variable = $3,000.

Same as before. At $100M/month (assuming some growth), the bill becomes $4,500. That added difference is captured without a sales conversation - excellent!

Choosing what to meter

Pick the metric that correlates with value, not with your infrastructure cost.

"API calls" is a lazy infrastructure metric that usually carries no value to the customer. For AI agents, "Documents processed," "transactions settled," "leads verified" are much more value-aligned.

Find out: can a non-technical user predict their bill next month based on what they plan to do? If not, you should consider changing the metric.

Packaging the tiers

Three categories matter here:

1. A leader is a capability more than 50% of your target customers need. It goes in every tier above entry.

2. A filler is a nice-to-have that nudges customers up a tier but wouldn't sell standalone.

3. A killer is a feature 10-20% of customers want intensely, and it depresses willingness-to-pay across the whole base if you bundle it in, so sell it as an add-on.

One of the most common packaging failure I see is that companies put their killer feature in the entry tier because the team is proud of it, then wonder why the entry tier dominates and no one upgrades.

Anchoring the base fee

The base fee sets the psychological reference point. Everything above it feels like expansion, not cost.

So, set the base fee high enough that the usage charge feels like a value was just unlocked! "You're on the $2,000/month platform, plus $0.02 per call" is an easier pill to swallow than "we charge $200/month plus $0.20 per call" even if the math is the same for most.

Building the metering layer

The design is usually fine by this point, and the customer needs implementation.

A meter takes raw customer activity (an API call, a transaction, a scan) and converts it into a structured, billable metric. The event gets captured, it carries enough context to be priced, and it gets aggregated over the billing period.

A minimal event in Solvimon's structure looks like this:

{
  "meter_reference": "transactions",
  "customer_reference": "acme_corp",
  "timestamp": "2026-05-20T14:00:00Z",
  "meter_values": [
    {
      "reference": "amount_processed",
      "amount": { "currency": "EUR", "quantity": "749.98" }
    }
  ],
  "properties": {
    "region": "eu-west",
    "payment_method": "credit_card"
  }
}

{
  "meter_reference": "transactions",
  "customer_reference": "acme_corp",
  "timestamp": "2026-05-20T14:00:00Z",
  "meter_values": [
    {
      "reference": "amount_processed",
      "amount": { "currency": "EUR", "quantity": "749.98" }
    }
  ],
  "properties": {
    "region": "eu-west",
    "payment_method": "credit_card"
  }
}

{
  "meter_reference": "transactions",
  "customer_reference": "acme_corp",
  "timestamp": "2026-05-20T14:00:00Z",
  "meter_values": [
    {
      "reference": "amount_processed",
      "amount": { "currency": "EUR", "quantity": "749.98" }
    }
  ],
  "properties": {
    "region": "eu-west",
    "payment_method": "credit_card"
  }
}

meter_reference routes the event to the right meter. meter_values carries what you're billing on (a count, an amount, a quantity). properties carries the context you need for conditional pricing: which region, which model, which card type.

Setting up a meter in Solvimon

Create a meter by defining at least one Meter Value and one Usage Metric. The Meter Value is the raw thing you're counting or summing (API calls, EUR processed, documents generated). The Usage Metric is the aggregation: sum, count, max, or average.

Sum and count cover most hybrid models. Max matters for capacity-based pricing (peak storage, peak concurrent users). Average is a reporting concept more than a billing primitive, in most cases.

If you need attribute-based pricing (different rates by region, model, card type), add Properties to your meter. Properties have to be marked as Required to work in pricing rules.

Once values and properties are defined, save and activate the meter. It sits in draft mode until you are ready.

Real-time vs. batch ingestion

You need to consider two paths.

In real-time: your application emits events at the point of action via API. Right for usage caps, in-product dashboards, anything where latency matters.

In batch: a nightly job pushes aggregated usage from your database or data warehouse (Snowflake, BigQuery, S3). Right for teams where real-time instrumentation is expensive or where daily granularity is enough.

Most teams end up with both: real-time ingestion for current-period tracking, batch jobs for reconciliation. The reconciliation job is the part people skip, and then they find a gap 6 months later - so.. Just consider that!

Putting it together: the pricing plan

A Pricing Plan in Solvimon is where you combine charge types into a single billable structure for a customer. The four common charge types are:

• Recurring: a flat fee charged on a periodic basis. Your base fee.

• Usage Based: variable, tied to a meter. Your consumption component. You can also include outcomes here.

• Seat Based: charged per allocated seat per period. Useful when part of your value scales with users.

• One-Off: charged once - like onboarding, implementation, admin fees.

All of these can live in one hybrid plan: one invoice, one contract, one place to configure it.

Creating a pricing plan

In Solvimon, navigate to Pricing Plans and click Create. Give the plan a name, set the billing period, then add your first charge (the recurring base fee). Click Add Pricing to include the usage-based component. Select the product, link it to the meter you created, set the pricing type (flat, tiered, volume), and define the amounts.

Once all components are added, activate the plan. It's ready to attach to a subscription.

Conditional pricing with Pricing Rules

If you need different rates based on usage attributes (card type, region, model tier), that logic lives in Pricing Rules. Define a default rate as the fallback, then layer conditions on top.

A card acquiring example: the first 100 cards at €0.20 per event, above that €0.10. Then a rule: if region = eu-west and card_scheme = discover and purchase_type = ecommerce, apply a specific rate for that combination. Conditional pricing at the event level, no custom code in your application, no spreadsheet reconciliation at month-close.

Pricing Groups for add-ons

If some customers buy additional components (a premium support tier, an add-on module, a capacity expansion), Pricing Groups let you configure those as selectable items within a plan or subscription. You pick one or more when creating the contract.

Useful for enterprise deals where the base plan is standardized but each customer has a custom combination of add-ons. The plan stays clean. The variation lives in the group selection.

Migrating flat-rate customers

The migration is where the pricing strategy meets the customer relationship. Most implementation guides skip it because it requires a bit of "change management" - we suggest that you think of this!

Start with new contracts

Launch the hybrid model with new customer contracts first. The first billing cycle will surface edge cases you didn't anticipate, and it's better to find that out with a handful of new customers than 50000 existing ones. Give yourself 30-45 days between new-contract launch and the existing-base migration.

Use that time to validate the model and build operational muscle around hybrid invoicing.

Segment before communicating anything

Pull 12 months of usage data per customer and put them in three buckets: low, mid, high consumption.

• Low-usage customers may pay more if the base fee exceeds their current flat rate. The risk is sticker shock.

• High-usage customers will pay more. The question is whether they see it as fair, or use it as a negotiation trigger.

• Mid-usage customers are usually the easiest, since the math often comes out similar.

Know the impact per customer before anyone on your team sends a single email.

Messaging by segment

For low-usage customers, anchor on the included allocation:

"You now get X units included in your plan before any usage charges kick in" - which is an easier pill to swallow, again, than "your monthly fee went up" which we all love getting.

For high-usage customers, volume tiers often improve their unit economics as they scale. Some will welcome it while others will use it as a trigger to renegotiate.

Don't see that as a failure - remember that the customers who push hardest on pricing during a migration are usually your most engaged accounts, which makes them candidates for a committed-usage deal that works for both sides. Be ready for that conversation.

Grandfather strategically

Blanket grandfathering is a terrible idea from my experience. But, with an entitlements system you don't have to! You can easily override the new plans with old features until you're ready to retire them or change them.

Either way, you should give a 3-6 month window with a clear transition date - it's reasonable and a best practice.

A cleaner structure: offer to honor flat-rate pricing for customers who commit to a multi-year contract within the migration window. That turns the pricing change into a commercial opportunity.

Communicate through your CS, sales team, and everyone who engages with customers - use it as a touch point to do a health check

Every customer above a meaningful revenue threshold should hear about the change from their account manager before it appears in an invoice. The customers who discover a model change through an automated email will escalate. That escalation costs more time and relationship capital than the call would have.

OK so what are the gotchas?

Revenue leakage from missed events

If events are dropped, delayed, or attributed to the wrong customer, you're delivering value you're not billing for. Most teams find this 6 months after launch when they run a reconciliation and find a gap. Run the reconciliation from the first billing cycle: compare total events emitted by your product against total events recorded by the billing system, per customer, per period. Any gap is a drop or a double-count. Catch it early.

Unclear invoices

A hybrid invoice is a more complex document than a flat subscription invoice. If a customer can't trace why their bill was $4,200 this month vs. $3,100 last month, you'll get disputes. Every metered line item should link to a usage report. A customer-facing usage portal (showing consumption by period, ideally before the invoice finalizes) kills most of these tickets before they happen.

Enterprise contract edge cases

Enterprise contracts regularly contain terms that don't fit standard billing models: base fee waived for the first 90 days, monthly caps on usage charges, minimum committed volume, multi-year pricing schedules with annual escalators. If your billing platform can't model these natively, you'll track them in a spreadsheet. The spreadsheet will eventually be wrong at the worst possible time.

Margin surprises at month-close

High-usage customers can look great on an ARR dashboard while destroying gross margin. Run a cost-vs-revenue reconciliation per customer cohort, not just in aggregate. Your top 10% of users by consumption should be generating margin above your cost floor. If they're not, the usage pricing needs revisiting, not the sales motion.

FAQs about hybrid pricing

What's the difference between hybrid pricing and usage-based pricing?

Usage-based is pure consumption: no fixed commitment, you pay for what you use. Most products described as "usage-based" are hybrid in practice, because they include a minimum commitment, a base fee, or an included allocation. Clay, Cursor, Figma, all hybrid. The distinction matters operationally because pure usage-based billing has no floor, which creates revenue volatility and forecasting problems for both sides.

How do I handle free tiers in a hybrid model?

Include a usage allocation in the base fee. The "free tier" is just the included units that don't trigger additional charges. When customers exceed the allocation, metered charges kick in. This is cleaner than a separate free-tier product because it ties the included usage to a paying relationship from the start.

What's the minimum viable metering setup to go live?

One meter, one usage metric, one data source. Real-time streaming isn't required on day one. A daily batch upload from your database is enough to validate the model in production. Add real-time ingestion when you need usage caps, in-product dashboards, or sub-daily billing cycles. Don't over-engineer the metering layer before the pricing model is validated with real customers.

How do I prevent revenue leakage when moving from manual to automated metered billing?

Run a reconciliation check from the first billing cycle. Total usage emitted by your product vs. total usage received by the billing system, per customer, per period. Any gap is events dropped or events double-counted. This check should run automatically every billing period, not just at launch.

How do I communicate a pricing model change to enterprise customers mid-contract?

Directly, early, and through the account team. Segment customers by bill impact before communicating anything. Give 60-90 days of notice with a clear transition date and a bill estimate using their actual historical usage. The customers who push back hardest are usually your best expansion candidates, so treat the conversation as commercial, not defensive.

When should I move from hybrid to outcome-based pricing?

When two things are true: the product can reliably deliver a measurable outcome (not just actions that contribute to one), and you have the telemetry to attribute it cleanly. Hybrid pricing is often transitional, the stepping stone between flat subscription and outcome pricing. GitHub Copilot is the textbook case: started per-user, moved to hybrid with AI credits, now positioning autonomous agents as per-outcome. Each move followed an actual capability shift. Don't jump to outcome pricing before the telemetry is there to support it.

Solvimon handles the billing infrastructure for this kind of complexity: metered events, conditional pricing rules, multi-charge-type plans, contract-level customizations. Talk to the team if you're building this out.