Credit-based pricing: when it works, when it doesn't, and how to get the architecture right
Maarten Laruelle Most founders discover credits the wrong way: they see a competitor using them and wonder if they should too. The better question is whether credits solve a specific problem you actually have. I’ve used them in two very different situations. The architecture looked nothing alike. What they had in common was the problem underneath.
Let’s start with the example of a health analytics company I worked with that had a revenue problem that had nothing to do with their product. Their product worked, customers were happy and the pipeline was growing. But they wanted to engage external funding and every conversation with a potential investor ended the same way. Show us your MRR/ARR. And the founders had nothing clean to show, because revenue came in waves. The pattern in their business was that their clients were busy in January, busy after summer, dead in August, quiet over Christmas. Which made complete sense if you understood the business as health awareness is seasonal. People don’t think about their health on a predictable monthly schedule.
Their pricing at the time was simple: pay per analysis when you need one. Perfectly logical for their customers but not ideal at all for the funding conversations.
The answer wasn’t a better pitch deck. It was a different payment structure.
That brought us to credit-based pricing. It is a payment structure that sits between flat-fee licensing and pure pay-as-you-go consumption. The customer commits to a budget upfront, receives that budget as credits, and consumes those credits flexibly over time against a published rate card. There is no one-to-one relationship between a credit and a euro. One credit might represent a €250 health analysis or a €0.30 compute job. The pricing is fully transparent. But the customer isn’t watching euros leave their account with every click. They’re watching credits. That decoupling is the whole point.
What I want to walk you through here are two situations where credits solved a real problem, the architecture each one required, and the decisions that made or broke each design. But first, the question that matters most: does credits actually solve a problem your customer has, or does it just sound sophisticated?
When credits solve real problems
Pattern 1: you need predictable revenue, your customer needs consumption flexibility
Back to the health analytics company. They were preparing for a funding round. That means investors want ARR and MRR, not bumpy project revenue. The problem was that the nature of health analysis doesn’t cooperate with predictable monthly billing. Practices ordered when patients needed it. Perfectly reasonable but completely at odds with what investors want to see.
The solution here was a yearly commitment converted to monthly credit deposits.
Those practices are also not super literate about budgeting and planning. Helping practices understand and commit to how many analyses they expect to run in a year was part of the sales conversation, but it gained extra trust rather than creating pushback. That yearly number becomes a monthly invoice, credits land in their account, and they consume against a fixed rate card. A standard analysis costs a fixed number of credits. A premium analysis costs more. They can save one month and spend more the next. From the company’s side, revenue becomes smooth. From the practice’s side, the ordering process was automated and helped them with financial planning and growth.
Here is what the commitment structure looked like (numbers are illustrative, structure and ratios are real):
| Yearly commitment | Monthly invoice | Monthly credits | Yearly credits | Effective discount |
|---|---|---|---|---|
| €5,000 | €417 | 450 | 5,400 | 8% |
| €10,000 | €833 | 940 | 11,280 | 11% |
| €20,000 | €1,667 | 1,960 | 23,520 | 15% |
| €35,000 | €2,917 | 3,500 | 42,000 | 17% |
| €50,000 | €4,167 | 5,200 | 62,400 | 20% |
And the rate card for consumption:
| Analysis type | Credits required | Effective price at €5K tier | Effective price at €50K tier |
|---|---|---|---|
| Standard analysis | 200 | €185 | €160 |
| Premium analysis | 270 | €250 | €215 |
Higher commitment, lower effective price per analysis. The practice can mix and match between types however their workload demands. The discount scales with commitment but stops at 20%. That cap matters because below 20% you’re rewarding commitment but above it you’re buying revenue at margins you’ll regret later.
Two decisions that need answers before you would go live with such a design.
What happens when a practice burns through credits faster than expected? You build in a controlled overdraft, roughly 25% of yearly commitment as a buffer. A practice on the €5,000 tier can go €1,250 negative before hitting a hard stop. High enough to handle normal variation, low enough to protect your cash flow. When a practice gets close to the limit, that triggers a customer conversation, not a system error. The team I worked with monitored this closely. It gave them an early signal when a practice was growing faster than their commitment, which is exactly the kind of conversation you want to be having.
The harder decision: what happens when a practice committed to €10,000 but only used €7,000 worth of credits by renewal? No rollover. Credits expire.
I know that sounds harsh. But without expiry, practices commit low, accumulate surplus year after year, and their effective cost per analysis drifts toward zero. Expiry forces an honest conversation at renewal. And that conversation should be happening in month six, not month eleven. If you’re monitoring usage properly, you catch undercommitment well before the contract ends.
Credits also support a second axis of value that sits entirely outside the credit rate. Features, support levels, marketing access. Here is how it layered in this case:
| Tier | Support level | Marketing support | Platform features |
|---|---|---|---|
| No commitment | Self-serve | Basic materials | Core features only |
| €5,000+ | Dedicated success manager | Premium visibility | Full platform access |
| €10,000+ | Priority support | Co-marketing opportunities | Beta features |
| €20,000+ | Named account executive | Dedicated marketing budget | White-label options |
A practice choosing between €5,000 and €10,000 isn’t just calculating credit rates. They’re also weighing a dedicated success manager versus priority support, co-marketing access, beta features. That is a very different conversation than “how many analyses do you think you’ll run?” Higher commitment isn’t just a lower price per credit. It’s a different relationship.
The finding from this work that surprised me most: small practices started reporting more trust in the company after the switch, and it had nothing to do with the product. It was the transparency. The monthly deposit, the credit balance, the usage summary. They could see exactly what they were spending and on what. That legibility built a kind of confidence in the vendor that a simple invoice per order never had.
The credit is not a discount mechanism. In this case it was a funding lever, and an unexpected side effect was that it created more trust between practices and the vendor than either side had anticipated.
Pattern 2: your buyer has budget but cannot predict usage
I want to start this one with a sentence that most founders don’t get to say very often: the customer has the budget. My client was selling an R&D optimization platform to large enterprises. Pharmaceutical companies, automotive manufacturers, industrial firms. Their platform generates experimental designs and runs computational analysis, replacing work that scientists would otherwise do manually, in legacy tools or Excel.
The buyers had innovation budgets. Typically somewhere between €25,000 and €100,000. But nobody could predict how they would use such a platform. A team might run 20 complex designs one quarter and 3 the next all depending on which projects were active. Sales conversations kept stalling at procurement because procurement does one thing before they approve anything: they ask for a number.
“How many designs do you need?”
“Unknown.”
“Then we cannot quote.”
It got to the phase where procurement wanted unlimited access at a fixed fee. That would have set a pricing precedent that was not ideal for my client. Walking away meant losing deals that were genuinely close. The company needed a structure that gave procurement the fixed number they needed, while giving R&D teams the flexibility they needed to actually use what was bought.
The answer was three distinct entry points built on a single credit currency.
Option 0: no commitment
For customers testing the platform or with a one-off need.
| Package | Price | Credits | Price per credit |
|---|---|---|---|
| Discovery | €4,500 | 5,000 | €0.90 |
| Innovate | €7,000 | 8,000 | €0.875 |
| Scale | €9,500 | 11,000 | €0.86 |
One purchase, no platform fee, credits valid for one year. This option exists for procurement simplicity. “We want to spend €7,000 to evaluate this.” One purchase order, one invoice, done.
Option 1: design-only subscription
For customers ready to commit to a recurring budget for design capabilities. Annual platform fee of €5,000, then monthly subscriptions that deliver credits at a much lower per-credit rate.
| Package | Monthly subscription | Monthly credits | Price per credit |
|---|---|---|---|
| Discovery | €1,650 | 5,000 | €0.33 |
| Innovate | €2,475 | 8,000 | €0.31 |
| Scale | €3,300 | 11,000 | €0.30 |
Total annual investment for Discovery: €5,000 platform fee plus €19,800 in monthly subscriptions. 60,000 credits at €0.41 effective per credit once the platform fee is included.
Option 2: design and compute subscription
For teams needing the full workflow. Same platform fee, higher monthly subscriptions, more credits, full access to the compute stack.
| Package | Monthly subscription | Monthly credits | Price per credit |
|---|---|---|---|
| Discovery | €2,450 | 8,000 | €0.31 |
| Innovate | €3,300 | 11,000 | €0.30 |
| Scale | €4,900 | 17,000 | €0.29 |
Total annual investment for Scale: €5,000 plus €58,800. 204,000 credits.
Credit consumption is tiered by complexity. And this is where it gets interesting: standard designs are free.
| Tier | What it covers | Credits |
|---|---|---|
| Tier 0 | Standard designs | Free |
| Tier 1 | Advanced designs | 500 |
| Tier 2 | Complex designs | 1,000 |
| Tier 3 | Enterprise-grade designs | 2,000 |
Compute works the same way. Basic analysis is free. Complexity is where credits get consumed.
Tier 0 being free is deliberate. Scientists do basic work without watching their credit balance. The platform becomes routine before it becomes a cost center. By the time they’re running complex, high-value projects where credits matter, the tool is already embedded in how they work.
The €5,000 platform fee is not a cost-recovery line item. It is a qualification gate. Anyone can buy credits in Option 0. Only customers with genuine intent commit to the annual platform fee. Those who don’t just stay in Option 0 and pay the higher per-credit rate. That difference is built in on purpose. The platform fee also solves another problem: enterprise complexity, user management, security, audit trails. That gets priced into the platform rather than awkwardly layered onto per-user pricing.
One thing I want to highlight about this design that I genuinely like: the package names. They could have gone with Bronze, Silver, Gold. Instead they used Discovery, Innovate, Scale. Names that reflect how the buyers think about themselves. In enterprise sales, naming is part of packaging. When your buyer identifies as an innovator, buying the Innovate package lands differently than buying the Silver tier, even if the contents are identical.
The procurement conversation changed:
Before: “How many designs do you need?” “Unknown.” “Then we cannot quote.”
After: “Based on similar teams, Option 2 Innovate covers roughly 10 complex projects per year. If you need more, you upgrade. If you need less, you still have the full platform and historical data. Does €44,600 annually fit your innovation budget?” “That we can approve.”
Same product worked out with a different structure allows to give procurement a number while R&D gets flexibility.
Credits solved a procurement friction problem, not a pricing problem.
One thing that makes this three-option design work in practice: a customer starting in Option 0 uses the same credit currency they will use in Option 1 or 2. No learning curve when they upgrade. Their mental model stays consistent, and the habit they built as an evaluator carries straight into committed use.
The two patterns side by side
Both cases use credits. But look at how different the implementations are:
| SMB practices | Enterprise R&D | |
|---|---|---|
| Primary problem | Revenue predictability | Procurement friction |
| Entry points | Single model with commitment tiers | Three options with different commitment levels |
| Platform fee | None | €5,000 for committed options |
| Free usage | None | Tier 0 designs and compute |
| Invoicing | Monthly deposits | One-time (Option 0) or monthly (Options 1 and 2) |
| Discount mechanism | Bonus credits | Lower price per credit + bonus credits |
Same payment structure. Different architecture. The architecture follows the buyer.
When credits are not the answer
Credits add operational complexity. You need to track balances, handle edge cases, manage overdraft and expiry, communicate usage status regularly. That overhead is worth it when credits are solving a real problem. It is not worth it when you’re just reaching for a pricing structure that sounds sophisticated.
Skip credits when usage is highly predictable. A subscription is simpler and your customers will prefer it. Skip them when customers can’t estimate their annual needs at all, because credits feel like gambling without a reference point to commit against. And skip them when your customer base is too small to justify running a credit system with proper monitoring, renewal conversations, and overdraft management.
The right situation for credits is asymmetry. What I mean is that you need the commitment and your customer needs the flexibility. When both sides are predictable, subscription wins. When neither is, you’re adding noise.
As you notice, credits ask for a bit more client conversation after the sale. You want to follow up closely on how they are using credits and make sure they are consuming them in time, or if they are moving fast, that you talk to them about an upgrade before they hit the limit. What proved true with both of my clients was that this overhead was worth the effort. It gave their clients trust, because they were transparent and thought with the business. And for my clients it made sense, because keeping an eye on consumption gave them better and more constructive conversations with their clients than they had ever had before.
And a important bonus was not highlighted yet!
In a normal subscription model, testing new functionality means a commercial conversation. A new module, an upsell proposal, a decision-maker who wasn’t in the room when the original deal was signed. The customer has to say yes before they’ve seen the value.
With credits already in the account, that changes. “We shipped a new analysis type. It costs 80 credits to run. You have 400 in your balance. Try a few.” No purchase order. No approval loop. The budget is already there. You’re inviting them to use it differently.
The sale comes after value is proven, not before. By the time they want to run more of the new capability, the question isn’t “should we buy this?” It’s “how much should we commit going forward?”
Credits don’t just work as a pricing model, they work as a growth model. The commitment creates the budget and the budget enables frictionless expansion. The expansion justifies a larger commitment at renewal.
The credit design checklist
These are the decisions that determine whether a credit system holds up or starts causing problems six months in. Think them through before you build, not after your first renewal cycle.
| Decision | What you need to answer |
|---|---|
| Invoicing rhythm | Monthly matches how small customers budget. Annual upfront is better for your cash flow but raises the commitment hurdle. |
| Fixed vs variable credit cost per service | Variable sounds nuanced but creates uncertainty. Customers need to calculate “I need roughly X, so I should commit Y.” Make the math clear. |
| Expiry vs rollover | Credits expire at renewal. Without expiry, customers commit conservatively and accumulate. Expiry keeps renewals honest. |
| Overdraft buffer | Around 25% of commitment handles normal variation. Set the number, communicate it clearly, and monitor it actively. |
| Platform fee | If you’re selling to enterprise, a platform fee separates evaluators from committed customers. It also lets you price platform complexity separately from consumption. |
| Tier 0 free usage | Make the simplest version free. It builds habit. It reduces balance anxiety. Capture value on complexity, not on basics. |
TL;DR
Credit-based pricing sits between flat-fee subscription and pure consumption. The customer commits upfront, receives credits, consumes flexibly. The architecture that makes sense depends entirely on the problem you’re solving. Revenue predictability for SMB buyers calls for a different design than solving procurement friction at enterprise. Both use the same payment structure. The architecture follows the buyer, and if neither of those problems sounds like yours, skip credits entirely and use a subscription.
Frequently asked questions
What is credit-based pricing in SaaS?
Credit-based pricing is a payment structure where customers commit to a budget upfront, receive that budget as credits, and consume those credits against a rate card over time. There is no direct one-to-one relationship between a credit and a euro. That decoupling gives customers flexibility in how they consume a committed budget, while giving the vendor predictable upfront revenue.
When should a SaaS company use credits instead of subscriptions?
When there’s an asymmetry: you need committed revenue, your customer needs consumption flexibility. If usage is predictable on both sides, a subscription is simpler. The right situation for credits is when a customer can estimate their annual budget but not their exact monthly usage pattern.
How do you set the right number of credits per tier?
Start from actual usage data. Look at what low, medium, and high users consume over a year. Design commitment tiers around those bands. Then set credit costs per service at a rate where a customer can look at their tier and confidently calculate whether it covers their needs. In your communication, give them example scenarios with simulations.
Should credits expire or roll over?
Expire. Without expiry, customers commit conservatively and accumulate a surplus year over year. That surplus creates pricing pressure at renewal and distorts your revenue metrics. Expiry forces honest conversations before renewal, which is exactly where you want to be. And those conversations are not bad, you can still be flexible when needed.
What is the difference between credit-based and usage-based pricing?
The direction of cash flow. In usage-based pricing, the customer pays after consumption. In credit-based pricing, the customer commits before consumption. Both link revenue to usage. Credits flip the billing sequence: you invoice upfront, they consume later. That is why credits work well when you’re building toward ARR, where pure usage-based pricing produces after-the-fact, unpredictable revenue.
How do credits help with enterprise procurement?
Procurement needs a fixed number to approve. When consumption is unpredictable, usage-based pricing makes that impossible. Credits convert an open-ended question into a fixed annual budget that procurement can process. R&D gets the flexibility to allocate that budget however their project pipeline demands. The credit structure gives both sides what they actually need.
For how pricing architecture fits into a broader model, start with the pricing guide. For founders managing multiple pricing models, see Multiple pricing models: drawing a clear line. Or learn more about the method behind how I approach pricing decisions at Tsjirpa.