DEV Community: ryan echternacht

Beyond the API: Why Critical Infrastructure is Going Streaming

ryan echternacht — Wed, 25 Mar 2026 16:30:04 +0000

The Request-Response Era

For the past 15 years, APIs have been the foundation of how software systems talk to each other. RESTful APIs gave us a clean mental model: your application asks a question, a service answers. The pattern was straightforward and it worked. We've built many products this way.

But then Google Docs came along and demonstrated a new model for a web application. Multiple people editing the same document simultaneously, seeing each other's cursors move. Changes appearing instantly, no refresh button, no "save and reload," or no conflicts to manually resolve. It felt like magic.

That experience redefined how we thought about building software. If a document editor could work like that, why couldn't everything else?

A generation of infrastructure companies took that question seriously. Firebase built a database that synced state across every connected client automatically, worked offline and caught up seamlessly when it reconnected. Pusher made real-time pub/sub something any developer could use in an afternoon instead of a months-long infrastructure project. LaunchDarkly architected feature flags so thoroughly that your application keeps running even if their entire service goes offline. Convex made databases reactive, with queries that automatically stay up-to-date as data changes, like React components rerendering.

These products fundamentally changed what's possible to build. Real-time collaboration stopped being a feature only Google-scale companies could afford. Live updates became the default instead of the exception. Data flows to where it's needed, state lives locally, and checks happen instantly. The infrastructure just works, even when networks don't.

What else could we build this way?

The Pattern: Stream State, Evaluate Locally

Here's what these tools actually do differently.

Traditional infrastructure waits for you to ask. You make an API call when you need data and the service responds. You cache the result if you're smart about it and you invalidate the cache when... well, hopefully you get that right. You write retry logic for failures, handle timeouts, and deal with stale data. It's a lot of work to make something that should be simple actually reliable.

Streaming infrastructure inverts this. The service maintains an open connection to your application, usually through WebSockets. When data changes on the server, it pushes updates to your client. Your application keeps a local copy of the state it needs. When you need to check something, you're reading from memory, not making a network request.

LaunchDarkly streams all your feature flags to your application on startup and keeps them updated. When you check if (flags.newFeature), you're reading from memory, not making an HTTP request. It's fast and can fallback to the last known value if LaunchDarkly's API is unreachable.

Firebase does this with your entire database. Query for data once, and Firebase keeps it up-to-date automatically. When another user changes something, the server pushes the update to you. You write code as if the data is just always current, because it is.

Convex takes it further. Your queries are TypeScript functions that run in the database. The database tracks what data each query reads. When that data changes, the query reruns automatically and pushes the new result to your client. You no longer need to matain logic to handle data refresh and caching.

In each case, your code works with the up-to-date start locally, while the service handles the difficult (and often error-prone) work to keep that state fresh.

Why This Wins for Critical Infrastructure

Developer experience. You outsource the hard parts—connection management, state synchronization, retry logic, cache invalidation—to the service. Your code gets simpler. You're not maintaining WebSocket reconnection logic or figuring out when to invalidate cached data. The infrastructure handles it, and you focus on building your product.

Reliability. The service being down doesn't mean your application stops working. You have the last-known state and can continue operating with it. LaunchDarkly explicitly designs for this, ensuring your feature flags work even during complete outages. You're not writing code to handle "what if the billing check fails", you’re using the last known billing state stored locally. The trade-off is that state might be slightly stale during an outage, but you can provide service instead of showing errors.

Performance. Because state lives locally, you avoid API calls in hot paths. Checking a feature flag or permission doesn't add 50-100ms to your request. You can check things in tight loops, on every request, without worrying about the performance impact.

What's now possible. Real-time collaboration used to require significant infrastructure investment. Now it's a weekend project with Firebase or Convex. Instant feature rollouts across your entire user base? LaunchDarkly makes it trivial. It's interesting to see what becomes buildable when the infrastructure gets out of the way.

The Engineering Challenge

Building streaming architecture means taking on significantly more surface area than traditional request-response services. In addition to the normal challenges of building a service, you're now responsible for persistent connection management at scale, WebSocket reconnection logic, backpressure handling, and ordered delivery guarantees. State synchronization becomes your problem—initial loads, incremental updates, consistency during network partitions, detecting and recovering from stale state.

With a traditional API, a lot of this complexity lives on the client side. Developers handle their own caching, write their own retry logic, manage their own state invalidation. It's work, but it's their work. With streaming, you're taking that work on yourself. You're promising the data will always be current, connections will stay alive, updates will arrive in order.

The companies that get this right change what's possible to build. These are the tools the next generation will learn from.

The Future of Infrastructure

It makes sense when you think about it. The infrastructure developers use most, the stuff that gets checked constantly, lives in hot paths, and needs to be fast and reliable, benefits from being local. Streaming state instead of fetching it solves real problems: better performance, simpler failure modes, and less code to maintain.

Request-response still has its place. Mutations, writes, and operations you do once in a while. But for the things you check all the time, streaming is starting to look like the better default.

More infrastructure will probably head this direction. The engineering is hardbut the companies doing it well make that complexity disappear for their users. When infrastructure gets out of the way like that, you can focus on building what actually matters.

Setting Your First Price: A Founder’s Practical Guide

ryan echternacht — Mon, 22 Sep 2025 19:23:43 +0000

We spend a lot of time with founders working through early pricing. The specifics change, but the guidance is remarkably consistent. This article lays out a practical starting point for setting your first price.

The most important advice we give is this: your pricing will change. Pricing is a tool, and you will want it to accomplish different goals at different times. Later on, that goal may be rapid growth, competitive positioning, or profitability. Early on, the goal is to learn quickly.

"A lot of bigger orgs... every 6 to 12 to 18 months, they’re thinking about how should pricing change." -- Fynn Glover, CEO, Schematic

There are 3 main steps in early pricing:

Choosing an initial price
How to determine your next price
How to continue to iterate on your price

Choosing an initial price

"So at first, when you're just going to market, you're optimizing for what's the fastest way to communicate value and sell what you have.” -- Gio Hobbins, CPO, Schematic

Many founders stress over “getting the number right” on day one. You don’t need to! If you’re entering an existing market, start with a flat monthly price at roughly half the going rate for comparable tools. If you’re in a new or ambiguous category, pick a number your ideal buyer can put on a credit card without thinking twice. Your goal is to avoid sticker shock and a) prove that some people are willing to pay for your product and b) build a set of 5-10 customers who you can learn from.

Your first plan should probably include unlimited usage of your product. Gio routinuley tells founders they want "the easiest way to just say this thing costs X per month." You'll have plenty of time to introduce usage or credit based pricing in the future. For now, focus on landing your first cohort of customers.

How to determine your next price

"If you guys spend your life building something for three years and nobody's willing to pay for it, that is a waste of your time." -- Fynn

While you're first price was just to get rolling, your next prices should be more thoughtful and data driven. To start, you'll need to talk people who could buy your product. You want to start this process early as possible -- the sooner the better! Put your product in front of your prospects and treat the conversation as a fact-finding exercise, not a sales call! If you're product isn't ready yet, you can use a Figma mockup or a prototype built in Loveable instead.

You want to talk to as many people as possible. Start with people in your network. Then, after each useful call, ask for introductions to two or three others who have a point of view on the problem. You’ll quickly build a small pipeline of conversations.

Fynn recommends 3 ways to hone in your pricing, based on how well you understand the market. These work for both Consumer and Enteprise products:

Known category, strong sense of the market

If you have a strong sense of the market already, we suggest choosing the price you think makes sense, then asking your prospects the following multiple choice question to verify you're choice. You can also use this to explore a few different price points. Start with a demo of the product, then ask:

This tool costs X per month. Based on what you anticipate this product's going to do for you, which of the following best describes your willingness and intent to purchase?

I would purchase this product immediately and I have the authority to do so.
I would advocate for purchasing this product at the stated price, but I would need to get approval from others, which I believe is achievable.
I'd consider purchasing this product, but significant internal approval would be required, and I'm uncertain of the outcome.
At the stated price, the product is beyond our current budget or cost expectations.

If most answers land in 1 or 2, you’re in range. If they cluster in 3 or 4, test lower price points.

Known category, weak sense of the market

If you’re in a known category, but don't have a strong sense of the market, you can use relative value to find your next price point. “Is this ~50% of the cost of the tool you use today? 100%? more?” Probe your prospect to how they are comparing you to their current tool and what they value most. This is a good way to understand how you stack up against other tools in the category. When you first start, you're likely to be perceived as lower value than existing tools in the market. With time, you will close the gap as your product matures.

Unknown category

If you truly don’t know where to start with your pricing, use an open ended question to determine a price ceiling. We suggest "What’s the maximum you’d pay before it feels unfair?" or “At what price would you say ‘that’s crazy’?" to find a price ceiling. Likewise, "At what price is this product a 'no-brainer' and you'd buy it immeditely?" can help you identify the price floor. Together, they will help you build a price range for your product.

Regardless of which approach you use, you'll want to have at least 5-10 conversations to start. Use the same script in each and remember, you're here to learn, not sell. Letting founder charisma take over is one of the most common mistakes we seen when trying to identify pricing.

You’re ultimately looking for convergence. You want to find the value metric that feels most intuitive to buyers and a clear price band between “no-brainer” and “prohibitive”. You're also hoping to find practical insight into how customers would buy. Then you’ll be ready to adjust your initial price with confidence.

How to continue to iterate on your price

"You can screw up your brand reputation with a bad pricing change." -- Fynn

As you grow, your pricing will change as well. Treat each change as a deliberate adjustment to what you want pricing to accomplish right now. Start by identifying the objective you hope to achieve. Are you optimizing for faster adoption? Stronger unit economics? Clear positioning against competitors? This choice should guide how you setup your plans and determine the price points you set.

When you do change your pricing, we suggest leaving existing customers on their current plans whenever possible. Offering "Legacy" Plans (or a long, migration window) improve customer trust and reduces churn risk when pricing changes. Move legacy customers only when there’s a clear reason, like materially new capabilities, higher service levels, or a cost structure shift that you can explain plainly.

During a pricing change, communication is key to securing customer trust. State the new price, what’s staying the same, when the change takes effect, and what options they have (e.g. stay on legacy, migrate now, or migrate later). Provide a clear explanation of why pricing is changing and how a customer like them is likely to be impacted (if you can use actual usage data for the customer, that's even better).

Finally, make sure your main pricing maps to the value your customers receive. If you're an email marketing platform, pricing on sent emails is good; even better would be pricing on opened emails. If you discover that your current lever (e.g. seats, requests, assets, tickets resolved) no longer reflects value, be willing to change it. Expect more migration work, but it’s better to correct the metric than to keep “optimizing” a structure that customers perceive as arbitrary. A good test is whether customers understand how they’ll grow and feel comfortable that higher bills arrive only when they’re getting more value from the product.

Conclusion

Early pricing is a learning exercise, not a referendum on your product’s worth. Start simple: one plan, one number that reduces friction and gets you into real trials. Run at least 10 structured pricing conversations, capture what you hear in one place, and use that to refine your view of value and price.

As you grow, revisit pricing with a clear objective. Keep your main lever mapped to customer value, protect trust by communicating changes plainly, and leave legacy plans in place when you can. Done well, pricing is a lever you deliberately tune as you grow, not a constraint that gets in the way.

Build vs. Buy: The Real Cost of DIY Billing Systems

ryan echternacht — Mon, 22 Sep 2025 19:17:27 +0000

Most engineering teams don’t set out to build a billing system. They just want to launch.

So they wire up Stripe Checkout. Maybe define a couple of plans. Add some metadata for access control. Ship it.

But there’s no clear standard for how to implement monetization. No Rails for pricing logic. No Terraform for entitlements. So teams improvise — and end up reinventing brittle, ad hoc billing systems that are hard to maintain and harder to scale.

It’s not just inefficient. It’s dangerous infrastructure debt, and it compounds fast.

If we had to build it ourselves, it might be a 3–4 month project. -Andy Barker, Pagos

You’ll Build More Than You Think

Without a blueprint, you just start wiring things together. And before long, you’ve built an entire billing stack.

Here’s what that usually looks like:

Access Control & Entitlements

At first, it’s simple:

if company.plan == 'pro':
    allow_export = True

It works. It ships. And you move on.

But then:

You want to let a free user try out a paid feature temporarily.
Sales needs to unlock a feature early for a big customer.
A PM asks for a way to test feature gating in staging.

Suddenly, what started as a simple plan check becomes a tangle of special cases, overrides, and exceptions. Access logic is no longer predictable — it’s conditional, brittle, and scattered across services.

if (company.plan in ['pro', 'enterprise', 'growth'] or
    company.id in [12345, 67890] or
    company.trial_flags.get('export') == True or
    company.custom_flags.get('export_enabled') == True):
    allow_export = True
else:
    allow_export = False

There’s no audit trail. No way to see who has what. No way to answer simple questions like:

“Why does this user have access?”
“Can support toggle this without engineering?”
“How do we roll this out to 10 beta customers next week?”

This isn’t just messy, it creates drag across the entire company. Experiments become risky, custom deals require manual work, and support teams are stuck waiting on engineers to make even the simplest access changes.

Usage Metering & Enforcement

You introduce usage-based pricing — maybe for API calls, exports, or monthly active users. So you start tracking usage. You write custom aggregation logic. You sync usage events to Stripe. You add manual resets, alerts, and frontend checks.

What seemed like a small addition becomes a system of its own.

Now you have usage logic in your backend, your frontend, your Stripe integration, and maybe your alerting service too. There’s no single source of truth. Different parts of the stack have different views of what a customer has used, and whether they should still have access.

It’s not just hard to maintain. It’s hard to trust.

Admin, Support, and Customer Tools

Eventually someone asks:

“What plan is this customer on?”
“Do they have access to that feature?”
“Can I give them a one-time extension?”

At first, you answer those questions manually — maybe with SQL, maybe by digging through Stripe. Then the questions keep coming. So you build an internal tool to surface plan details. Then a dashboard to show usage. Then a quick way to toggle flags. Before long, you’ve built a support panel. And a customer portal. And probably a spreadsheet to track overrides, just in case.

But it’s not just your team asking for visibility — your customers want it too. They want to see what plan they’re on, how much they’ve used, what’s included, and what happens next. So now you’re maintaining UI components for usage meters, upgrade paths, and threshold alerts.

These tools aren’t optional. They’re necessary to keep the business running, but they’re expensive to build, brittle to maintain, and often locked away behind engineering. Every new feature or plan change means updating all the tools you duct-taped together last quarter.

What started as “just a couple of plans” now requires infrastructure just to answer basic questions about access, usage, and entitlements.

There’s a Better Pattern — But You Have to Choose It

Most teams don’t set out to build billing infrastructure — they just take one step at a time. What they don’t realize is that there’s a better way. Not because they’re doing it wrong, but because they don’t know that modern monetization platforms like Schematic exist.

Schematic gives you a foundation that turns ad hoc logic into real infrastructure:

A structured entitlement system, so access control is consistent, auditable, and easy to manage.
Centralized usage metering and enforcement, so you can charge based on consumption — without stitching together backend counters and cron jobs.
Flexible plan configuration and overrides, so trials, custom add-ons, and mid-cycle upgrades don’t require manual exceptions or code changes.
Built-in admin and customer portals, so support and success teams can do their jobs without filing tickets or asking for SQL access.

Instead of hiding logic in Stripe metadata, scattered flags, or backend conditionals, you manage monetization through a clean, purpose-built system. Instead of reinventing billing tools, you configure the ones you need. And instead of requiring engineering for every plan change, trial extension, or sales exception, GTM teams handle it themselves.

For engineers, that means fewer Slack pings, fewer one-off scripts, and fewer billing-related bugs. You spend less time maintaining brittle logic and more time building the product that actually moves the business forward.

It’s not just leverage for the business — it’s freedom for the team.

Billing Is Infrastructure — Build Your Product, Not the System Around It

There’s no standard playbook for monetization — which is exactly why most teams fall into the same traps.

But billing isn’t your product. It’s infrastructure. Just like auth, observability, or CI.

The longer you delay investing in it, the more glue code, tech debt, and edge cases you’ll accumulate. And the more painful it’ll be to replace later.

Don’t build the billing system you’ll one day need to rip out.
Build the product your customers are actually paying for.

Why Usage-Based Billing Is Taking Over SaaS

ryan echternacht — Wed, 30 Jul 2025 12:43:32 +0000

Introduction: Why Usage-Based Billing Is Taking Over SaaS

The days of one size fits all pricing are fading. As SaaS companies become more infrastructure heavy, API driven, and product led, pricing models need to evolve to keep up. One approach has emerged as especially flexible, scalable, and aligned with how customers want to pay: usage based-billing.

In a usage-based model, customers pay for exactly what they consume, whether that’s API calls, messages sent, data processed, storage used, or contacts reached. It’s a natural fit for modern SaaS products across categories, from developer tools and analytics platforms to sales, marketing, and productivity software. Whether you're building for operators, end-users, or embedded infrastructure, usage-based billing gives you a flexible way to map pricing to value.

When implemented well, usage-based billing can become a powerful revenue engine. When it’s poorly executed, it can lead to customer confusion, trust issues, and unpredictable results.

This guide walks through the key concepts, pricing models, benefits, and risks of usage-based billing, with a focus on what works in modern SaaS. Whether you’re just starting to monetize, rethinking your pricing strategy, or dealing with the complexity of scaling, this article is designed to help you make smarter decisions about how to charge for what you’ve built.

What Is Usage-Based Billing?

Usage-based billing is a pricing model where customers are charged based on how much of a product or service they consume. Instead of paying a fixed monthly rate or purchasing a set number of seats, customers pay in proportion to their actual usage.

At its core, usage-based billing is about aligning pricing with value. If a customer uses more of your product and gets more value, they pay more. If they use less, they pay less. This makes the model inherently scalable and often more appealing to customers who want pricing that reflects their growth.

What counts as “usage” varies by product. It could be:

Infrastructure-based: API calls, data processed, or storage used
Contacts reached, emails delivered, or CRM records enriched
Minutes of video processed or events tracked
Prompts submitted or tokens consumed in AI workloads

This model shows up across SaaS, from infrastructure to productivity tools. Usage-based billing supports a range of business strategies, from freemium and self-serve to enterprise sales and usage commitments.

Core Usage-Based Pricing Models

Usage-based billing isn’t a single approach. Most companies blend usage pricing with other models to balance flexibility, predictability, and customer trust. Here are the most common structures and when they’re useful:

Pay-as-you-go

Customers are billed purely based on what they consume within a given period, with no upfront commitment. This model is simple and transparent, but it can lead to revenue volatility and customer anxiety if not paired with good usage visibility.

Example: Twilio charges per API request or message sent, with no minimums or base fees.

Prepaid Credits

Customers purchase credits in advance and consume them over time. Credits can abstract away underlying complexity (like GPU time or tokens) and give customers more control over spend. They also help vendors collect cash upfront and smooth revenue.

Example: OpenAI sells API credits that can be applied to different models and endpoints, letting customers prepay for variable usage.

Tiered usage plans

Usage is broken into defined tiers (e.g. 0–10k units, 10k–100k units, etc.) with different per-unit pricing in each band. This can create incentives for customers to grow usage without jumping too sharply in price.

Example: Mixpanel offers volume-based pricing for tracked events, with lower per-event costs as usage increases.

Overages on top of a base plan

A common hybrid model, customers pay a fixed monthly fee for a certain amount of usage, and any usage beyond that is charged at a defined overage rate. This gives customers predictability while still allowing revenue to scale.

Example: Customer.io includes a set number of messages per month in each plan and charges overage fees for additional sends.

Commitments with usage flexibility

Larger customers often negotiate usage commitments in exchange for discounts. These may include minimums, tiered pricing, or pre-purchased usage blocks. It’s a way to introduce predictability into a usage-based relationship.

Example: Stripe offers committed-use pricing for enterprise customers, often tied to projected transaction volume and negotiated rates.

Why Usage-Based Billing Works for SaaS

Usage-based billing has gained traction because it maps revenue to actual product value. Instead of charging based on static assumptions, like number of seats or company size, usage-based models scale as customers grow and succeed.

Here are a few reasons why SaaS companies are adopting usage-based pricing:

It grows with the customer

As customers adopt more of your product or integrate it more deeply into their workflows, their usage naturally increases. Usage-based billing captures that growth without needing constant upsells or contract renegotiation.

It aligns price with value

Customers only pay for what they use. This feels fair, especially for early stage users or teams that are just getting started. As usage increases, so does the value they’re getting from the product, which makes higher bills feel expected rather than surprising.

It lowers the barrier to entry

Usage-based models often allow for low or no upfront cost, which makes adoption easier. This works well with freemium and product-led growth strategies, where the goal is to drive usage before monetization.

It encourages efficient usage

For products with meaningful marginal costs, like infrastructure, AI, or communications, usage pricing helps customers self-regulate. That can reduce misuse and help align usage with real need.

It supports long-term expansion revenue

As customers derive more value from the product and increase their usage, revenue grows in parallel. This dynamic contributes to strong net revenue retention across a wide range of SaaS categories, from infrastructure and analytics to marketing and collaboration.

Risks and Tradeoffs of Usage-Based Billing

While usage-based billing can unlock growth and improve alignment between product value and pricing, it also introduces complexity. Without thoughtful design, it can create friction for customers and operational challenges for your team. Here are some of the most common pitfalls to watch out for:

Runaway spend and bill shock

If customers aren't aware of how quickly usage can accumulate, they may be surprised by unexpected charges. This can erode trust, damage retention, and create support burdens, especially if billing feels unpredictable or opaque.

Tip: Set usage alerts, offer soft limits or caps, and surface real time usage data in the product to prevent surprises.

Confusing pricing models

Usage pricing often introduces new units (e.g. tokens, rows, API calls, or events) that customers may not understand. If pricing isn’t clearly tied to perceived value, it can lead to hesitation, frustration, or churn.

Tip: Use plain language to explain pricing units, and include examples of how usage translates to outcomes customers care about.

Revenue unpredictability

As customers scale up or down, so does your revenue, often in ways that are hard to predict. Without the right controls in place, this can make it harder to forecast, plan headcount, or communicate growth confidently.

Tip: Blend usage pricing with minimum commitments or base plans to improve predictability without limiting upside.

Complex implementation and operations

Metering usage accurately requires coordination between product, engineering, and finance. Without solid infrastructure, you risk underbilling, overbilling, or losing visibility into key customer behavior.

Tip: Unless you have a billing engineering team, consider using a modern monetization platform like Chargebee or Schematic that’s designed to handle usage-based billing out of the box.

Harder to sell or budget

In sales-led environments, buyers often want predictability, especially at the enterprise level. If usage pricing feels risky or hard to model, it can slow down deals or create friction during procurement.

Tip: Offer modeled cost scenarios during the sales process, and consider hybrid pricing with committed usage or volume discounts.

When Usage-Based Billing Makes Sense

Usage-based pricing isn’t the right fit for every SaaS product. But in the right context, it can create a tighter link between value and revenue, help your product scale with your customers, and support long-term growth.

Here are a few scenarios where usage-based billing tends to work well:

Products with real marginal costs

If your product has meaningful per-unit costs (e.g. compute, storage, or messaging volume) usage-based pricing helps you align revenue with your cost structure. It also encourages customers to use the product efficiently.

Integrated or API-first platforms

When your product is embedded in your customers’ workflows or applications, usage often tracks directly with business value. Charging per event, request, or object processed is intuitive and scales alongside adoption.

Freemium, PLG, or marketing-led funnels

Usage-based pricing lowers the barrier to entry and supports gradual monetization. Free or low-cost plans can include limited usage, while paid tiers unlock higher volumes or additional functionality. This helps convert active users into paying customers as usage grows.

Broad customer range across segments

If you serve both startups and enterprises, usage-based pricing adapts more naturally than flat-rate or seat-based models. Smaller customers can start with minimal usage, while larger customers can scale without changing plans or negotiating custom contracts.

Evolving Your Usage-Based Model

The first version of a usage-based pricing model is rarely the final one. As your product matures and customer needs become clearer, evolving the model can help deepen trust, reduce friction, and create new paths for growth.

Improve visibility and control

As usage grows, so does the need for customers to understand what they’re consuming. Make usage transparent within your product, and offer controls like alerts, soft limits, and usage estimators. This not only prevents surprises but also increases customer confidence in the pricing model.

Revisit how you measure and package usage

Over time, your original usage units may stop reflecting how customers perceive value. You might need to reframe pricing around outcomes instead of raw consumption, or introduce new abstractions like bundles, plans, or credits. These changes can reduce cognitive load and make it easier for customers to scale.

Iterate with care

Usage-based pricing evolves best when changes are gradual and well-communicated. Make space for legacy customers when necessary, and treat major pricing updates like product launches: test them, gather feedback, and introduce them with clear rationale.

Conclusion

Usage-based billing has become a defining model for modern SaaS, flexible enough to support diverse customer needs, and dynamic enough to grow alongside them. It aligns price with value, lowers the barrier to entry, and opens the door to long-term expansion.

But launching a usage-based model is just the beginning. The real work comes after: giving customers the visibility and control they need, refining how value is packaged and priced, and evolving your approach as both your product and customer base mature.

Usage-based billing can be an effective monetization strategy across a wide range of SaaS categories. When thoughtfully implemented and continuously improved, it offers a scalable way to align pricing with customer value while supporting sustainable growth.

Is a Credit-Based System the Right Fit for Your SaaS Pricing?

ryan echternacht — Tue, 29 Jul 2025 14:23:13 +0000

Credit-based pricing models have become increasingly common in SaaS, especially among products with complex usage or variable consumption patterns. Instead of charging customers directly for each request, feature, or seat, these models let users prepay for a pool of credits, then draw down against that balance as they use the product.

The approach isn’t new. Credit-based models have long been a staple in B2C products, from mobile games to freemium productivity tools. But recently, they’ve started gaining traction in B2B SaaS as well, offering teams a way to simplify packaging, unify multiple usage types, and give customers predictable spend.

This article looks at what credit-based systems actually are, where they make sense (and where they don’t), and what you’ll need to consider if you’re thinking about adopting one.

What Is a Credit-Based Model?

In a credit-based model, customers prepay for a set number of credits and consume them as they use the product. Each action — whether it’s an API call, export, or feature access — burns a specific number of credits, reducing the overall balance until the user needs to top up, renew, or upgrade.

This is different from postpaid usage-based billing, where customers are charged at the end of a billing period based on what they consumed. It’s also more flexible than flat-rate pricing, which typically assumes uniform usage across customers.

Credit-based models introduce a layer of abstraction. Credits aren’t always tied directly to a real world unit, such as one API call or one gigabyte of storage. Instead, companies often define their own internal pricing (e.g. “1 credit = 100 emails verified" or “10 credits = 1 video export”) to align pricing more closely with value delivered or cost incurred.

That abstraction is the core strength of the model. It gives companies room to evolve pricing, bundle multiple usage types into one system, and shield customers from backend complexity, all while offering a clear budget constraint.

Examples of Credit-Based Usage Across SaaS Categories

Category	Credit Usage Example	What It Abstracts
Design tools	1 credit = 1 high-res export	File size, format, or backend processing time
Email marketing	1 credit = 100 emails sent	Variable provider costs, batch size
Data enrichment	2 credits = 1 company profile lookup	Source-specific cost, data volume
Scheduling platforms	5 credits = 1 branded booking page	Premium features or integrations
PDF generation APIs	1 credit = 1 PDF rendered	File complexity or page count
Video platforms	10 credits = 1 minute of HD transcoding	Resolution, format, compute time
Analytics tools	1 credit = 10,000 events processed	Event volume and retention costs
Dev tools / CI/CD	1 credit = 1 test run or build minute	Compute time, concurrency
AI/ML platforms	1 credit = 1,000 tokens generated or 1 model inference call	Model size, latency, infra costs

Why SaaS Companies Use Credit-Based Models

Credit-based models offer SaaS companies a flexible way to charge for usage, without giving up predictability or control.

They’re especially useful when:

Customers want budget predictability, but usage isn’t consistent.
With credit-based models, customers prepay for a block of usage and consume it at their own pace. This smooths out variable usage patterns while giving finance teams a predictable spend.
Products have more than one usage dimension.
Credits can unify pricing across different actions (e.g. API calls, exports, or users) without showing customers a messy rate card. Instead of charging separately for each metric, you can price against a single pool.
Self-serve onboarding needs to be frictionless.
Offering a small set of credits up front lets users try the product without a time limit or forced upgrade. It’s an effective alternative to time-based trials, and maps better to actual value delivered.
Pricing needs to evolve without rewriting the contract.
Because credits abstract away implementation details, companies can adjust internal pricing (e.g. increasing how many credits an expensive feature consumes) without changing the customer’s billing agreement.
You want one system that works across go-to-market motions.
Credit-based models can support both self-serve and enterprise deals. Enterprise buyers can purchase large credit packages with volume discounts, while individual users can start small and scale usage over time—all against the same balance.

In short, credit-based systems give SaaS teams more flexibility in how they monetize, while helping customers stay in control of their budgets. That balance is hard to strike with traditional usage-based or flat-rate pricing alone.

Design Considerations

Credit-based models give you flexibility, but that flexibility introduces new complexity. To make them work in practice, you’ll need to think carefully about how credits are defined, communicated, and managed.

Make Credits Understandable

Credits are meant to simplify pricing, not obscure it. If users can’t quickly grasp what a credit is worth, or how many they’ll need to complete a task, they’ll lose trust in the system. Tie credits to recognizable actions (e.g. “1 credit = 1 export” or “10 credits = 1,000 events processed”) and keep the math intuitive.

Tip: Use plain language and real-world examples when describing what credits represent in your product.

Expose Usage Clearly

Users should never be surprised by their credit balance. Real time meters, dashboards, and low balance alerts build trust and help prevent unexpected lockouts. Additionally, you should also prompt users to top up before they run out. Ideally, do this in product, with clear context on their recent usage and what they’re likely to need next.

Tip: Show credit burn in real time, warn users early, and make reloading credits a one click experience.

Plan for Edge Cases Early

Expiration rules, top-ups, rollovers, and refunds often get added late, but they shape how fair and usable your credit system feels. Without clear defaults, support teams end up writing policy on the fly, and customers don’t know what to expect.

Tip: Decide and document these mechanics before launching, even if you start with simple defaults.

Let Credits Support Both Product-led and Sales-led Growth

Credit-based models work well across go-to-market motions. You can offer free credits to new users in a product-led motion, then scale up to larger committed credit packages in enterprise deals. The same system powers trials, usage-based upgrades, and negotiated contracts, without fragmenting your billing logic.

Tip: To make your pricing easy to understand, keep credit usage consistent across plans, and instead vary how many credits are included or how the cost scales across plans.

Price for Flexibility, Not Just Cost Coverage

Credits aren’t a 1:1 proxy for cost. If you tie them too tightly to backend expenses, you’ll limit your ability to adapt pricing as the product evolves. Instead, use credits as a flexible way to represent product usage, without exposing the raw cost behind every action.

Tip: Calibrate credits around perceived value, and leave yourself room to adjust as usage patterns shift.

Calibrate Credit Pricing Over Time

You won’t get credit pricing perfect at launch. As usage data comes in, you may need to adjust how many credits different actions consume, or how much credits cost per plan. A credit-based system allows you to adjust these inputs over time, without overhauling your entire pricing model or breaking customer trust.

Tip: Start with generous defaults, track effective price per feature, and reserve the right to rebalance as usage shifts.

Infrastructure Challenges

Credit-based models don’t just affect pricing, they shape how your product, billing, and finance systems need to work together. And most off the shelf billing tools aren’t built to handle them.

Here’s where things get tricky:

You need a credit ledger.
Credits aren’t just a pricing abstraction, they’re a balance that must be tracked, updated, and synced in real time. That means maintaining a source of truth for how many credits a customer has, what actions burned them, and when the next reset or top-up should occur.
You need real-time metering.
Unlike simple subscription billing, credit systems often require metering usage at the feature or action level. This data needs to be accurate, timely, and tied directly to the credit system, ideally with no lag between usage and burn.
You need entitlement enforcement.
When a customer runs out of credits, you need to enforce limits, either by disabling certain actions, downgrading access, or prompting for a top-up. This logic has to exist across your product, not just in your billing layer.
You need internal tooling for support and finance.
Teams need to see credit balances, drill into usage history, apply manual adjustments, and reconcile reporting. If credits expire, you’ll need clear visibility into liability and revenue recognition. This is where most legacy billing systems fall short.
You probably won’t get this from legacy billing platforms.
Most billing systems were designed for subscriptions, not dynamic credit balances. They don’t offer native support for tracking a credit ledger, enforcing usage-based entitlements, or evolving credit pricing over time. As a result, many teams end up building custom infrastructure to fill the gap.

Schematic is built for credit-based billing. With native support for entitlements, usage metering, and credit-based pricing, Schematic makes it easier to manage credit systems across both self-serve and enterprise plans, without custom infrastructure. Learn more here.

Where Credit-Based Models Don’t Fit

Credit-based systems offer flexibility, but they’re not the right solution for every product. In some cases, they can introduce unnecessary complexity or make pricing feel less intuitive.

Here are a few scenarios where credit-based models may not be a good fit:

Your product has a single, simple usage metric.
If your pricing is based on one well-understood metric (e.g. messages sent, users active, or seats provisioned) a straightforward usage-based or tiered plan is often easier for customers to understand.
Customers expect full cost transparency.
In some categories, especially those with technical buyers, abstracting usage into credits can feel like a black box. If trust depends on showing raw costs or usage inputs, credits may raise more questions than they solve.
Usage is flat or doesn’t vary meaningfully.
If your customers use roughly the same amount each month, or usage doesn’t scale with value, credits may add complexity without delivering any real benefit.

Conclusion

Credit-based models give SaaS teams a powerful tool for packaging and pricing usage, especially when products span multiple features, customer types, and growth stages. They offer the flexibility to adapt as usage patterns change, while still providing customers with the predictability they expect.

Done well, a credit-based system can simplify onboarding, unify pricing across plans, and support both PLG and sales-led motions. And because credits abstract away raw costs, they give you room to evolve your pricing model over time, without disrupting your users or your billing infrastructure.

Why AI Companies Are Turning to Credit-Based Pricing

ryan echternacht — Mon, 28 Jul 2025 20:42:10 +0000

Pricing AI products presents a unique set of challenges.

Infrastructure costs can vary significantly across models, workloads, and customers. Usage is often unpredictable, shaped by prompt inputs, model behavior, and user experimentation. Additionally, many of the underlying units (like tokens or inference time) aren’t intuitive for end users.

To address these issues, many AI companies are adopting credit-based pricing models. Rather than charging customers directly for raw usage, they offer a pool of prepaid credits that are consumed as the product is used. This approach creates a buffer between backend cost and customer experience, giving vendors more flexibility and customers more predictability.

This article looks at why credit-based models are particularly well suited to AI products, how teams are applying them, and what to consider when implementing one.

If you’re looking for a more general overview of how credit-based models work, check out our guide for SaaS companies.

What Makes AI Pricing Especially Difficult

Pricing AI products introduces challenges that don’t show up in most SaaS categories. The cost of serving users can swing dramatically based on their behavior, and the units involved aren’t always intuitive or easy to explain. That makes it difficult to design a pricing model that’s fair, predictable, and easy to understand.

Here are a few of the core challenges:

Infrastructure costs are highly variable

The cost of a single request can change based on which model is used, the length of the prompt, the size of the output, and where the workload runs. Two customers might make the same number of API calls, but generate vastly different costs.

Usage is hard to predict

Unlike traditional SaaS metrics like seats or reports, AI usage depends heavily on user input. A single prompt might trigger a cheap, fast inference, or a long, multi-step chain across multiple models. Small changes in behavior can have big cost implications.

The units aren’t intuitive

Tokens, embeddings, and context windows are useful internally, but don’t translate well for end users. Most customers can’t easily understand what they’re consuming, or how to estimate what they’ll spend.

Transparency can create friction

Trying to expose raw usage metrics often leads to confusion. But hiding them entirely can make pricing feel opaque or arbitrary. Striking the right level of transparency is a challenge, especially when pricing needs to scale across technical and non-technical users.

These issues make it difficult to align pricing with value, control costs, and maintain trust—all at the same time.

How Credit-Based Models Simplify AI Pricing

Given the challenges of pricing AI products—volatile costs, abstract units, and unpredictable usage, many teams are turning to credit-based models as a way to simplify the experience without giving up flexibility.

Credit-based models introduce an abstraction layer: instead of charging for tokens, seconds, or model calls directly, customers purchase a pool of credits and consume them as they use the product. This structure offers several benefits:

Create predictability without exposing raw costs

Credits give customers a consistent budget to work within, even if the underlying usage varies. That’s especially useful in AI, where costs can spike due to model complexity, retries, or unexpected prompt behavior. Instead of surfacing every technical detail, teams can communicate value through a simpler unit.

Bundle usage across endpoints or features

AI platforms often support multiple models or tools (e.g. chat completion, embedding, vector search). A shared credit pool makes it easier to unify billing across these without separate pricing for each one. This not only simplifies internal packaging, it also gives customers more flexibility in how they use the product, without locking them into one specific feature or use case.

Give customers more control over their usage

With a prepaid credit system, customers decide when to top up based on their needs. Instead of getting billed automatically at the end of a period, they can monitor their usage, plan their spend, and buy more credits on their own schedule. This flexibility can be especially valuable for teams with unpredictable workloads or capped budgets.

Allow pricing to evolve over time

Because credits are abstracted, teams can adjust how many credits different actions consume as cost structures or product usage changes. This allows pricing to evolve gradually, without overhauling the pricing model. And when handled well, these changes can happen without breaking customer expectations.

In short, credit-based models give AI teams a way to balance infrastructure realities with customer experience—offering a pricing layer that’s more stable, understandable, and adaptable.

Design Patterns That Work Well in AI Products

The flexibility of credit-based pricing is especially useful in AI, where usage can span models, workflows, and user types. But to make it work in practice, teams need to be intentional about how credits are allocated, surfaced, and managed across the product.

Here are a few patterns that work particularly well:

Vary credit costs by model type or latency tier

Different models have different cost profiles. A small open-weight model might cost 1 credit per call, while a proprietary GPT-style model could cost 10. This gives customers choice and aligns credit burn with infrastructure costs, without surfacing low-level details.

Tip: Use tiered or grouped pricing (e.g. “Standard” vs. “Premium” models) to keep things understandable without exposing every model’s raw cost.

Share a credit pool across multiple feature types

Many AI platforms support more than just inference. You might also offer file processing, embedding generation, vector search, or data storage. Rather than creating separate usage meters for each, you can deduct from a shared credit balance to simplify tracking and billing.

Tip: Keep burn rates proportional to underlying cost, but surface everything through a single, unified meter.

Show users how many credits each action consumes

Credits are abstract, but they shouldn’t feel arbitrary. In-product feedback like “this prompt used 12 credits” or “embedding this file will cost 20 credits” helps customers understand what they’re spending and why.

Tip: Show credit usage before and after actions, so customers can estimate cost and reflect on value.

Let users set usage caps or burn rate limits

Especially for teams with constrained budgets, giving users the ability to pause usage, set monthly limits, or receive threshold alerts can make credits feel safer and more trustworthy, while reducing support load.

Tip: Make it easy to monitor spend and set alerts directly in the UI or via API.

Monitor credit balance and prompt users to top up

Credit-based models only work if customers know where they stand. Regularly surfacing the remaining balance, and prompting users to buy more before they run out, helps avoid surprises and keeps usage flowing. Ideally, this happens well before usage is blocked or downgraded.

Tip: Set clear thresholds for when to show low balance warnings, and make reloading credits fast and frictionless.

Building for Credit-Based Pricing in AI Infrastructure

Credit-based pricing isn’t just a billing model, it’s a system that touches your infrastructure, product logic, and internal tooling. To make it reliable at scale, you’ll need more than just a credit balance in Stripe or a frontend usage meter.

Here’s what AI teams typically need to support it:

Real-time usage tracking at the request level

You need to measure usage as it happens, not hours later. That means logging every model call, embedding request, or file processed, ideally with enough metadata to understand what consumed credits and why.

Tip: Attach a usage event ID to each request so you can trace credit burns and resolve customer questions quickly.

Integrated credit logic in your product pipeline

Burning credits shouldn’t happen in a separate billing process. It needs to be part of your core product logic, especially if you're routing requests across models or applying fallback behavior. If a user runs out of credits, that decision has to be enforced in real time.

Tip: Credit validation should be fully integrated with your system for tracking and enforcing entitlements (feature access).

Entitlement enforcement is a core product decision

When a customer runs out of credits, what happens? Do you block usage, downgrade quality, or offer a fallback experience? These decisions need to be enforced in your product layer, and reflected consistently across UI, API, and backend systems.

Tip: Design for both soft and hard limits (e.g. warning tiers vs. absolute stop) to avoid abrupt user experiences.

Accurate reporting for finance and support

Support teams need visibility into credit usage to troubleshoot customer issues. Finance needs accurate data for reconciling prepaid revenue, handling expirations, and recognizing revenue correctly over time. If credit usage isn’t tracked and surfaced cleanly, it quickly becomes a liability, for both customer trust and financial compliance.

Tip: Make sure credit usage is easy to track, both for customer support and for finance. You'll need to account for credit expirations, refunds, and usage history—not just for clarity, but also for accurate revenue recognition.

Together, these systems create the foundation that makes credit-based pricing trustworthy—for both your team and your customers.

Schematic is built for this. With native support for usage tracking, credit balances, entitlements, and pricing logic, Schematic gives AI teams the tools they need to manage credit-based models—without building a custom billing system from scratch. Learn more here

Conclusion

Credit-based pricing offers a practical way for AI companies to manage variable usage, abstract technical complexity, and give customers clearer control over what they spend.

When implemented well, it supports a wide range of use cases, across models, workflows, and customer types, while keeping billing predictable and scalable. It also gives teams room to evolve pricing as infrastructure costs or usage patterns change.

They’re not trivial to implement, but for many AI companies, they offer a clear path through one of the hardest parts of building and monetizing AI products: turning usage into revenue in a way that scales.