Pricing Rule Engines vs. Hardcoded Billing Logic in SaaS

Hardcoded billing logic breaks the moment a SaaS company's pricing stops being one flat number for everyone. That moment has already come and gone for most of the industry: usage, credits, seats, and hybrid contracts have replaced the single-tier subscription as the default, and application code full of if-statements can't keep pace with how fast those models change now. I once sat in a pricing meeting where someone floated "just add a new tier" like it was nothing, and I watched an engineer go quiet doing the math on how many files that would actually touch. This piece covers why that shift happened, what it costs the companies that ignore it, and what a pricing rule engine does differently, mechanically.

Hardcoding made sense at a certain stage, and honestly, it still does. A company with one pricing model, one tier, and a handful of customers needs a few conditionals in the checkout flow, which is the fastest way to start charging money at all. No billing team exists yet, there's no budget for outside tools, and building for a scale that hasn't arrived is a week nobody has to spare. Fine at founding, all of it. Nobody goes back to revisit that call once the business outgrows it, though, and by the time someone does notice, the fix isn't a refactor. It's archaeology.

Pricing models multiply faster than most codebases can absorb. Stigg tracked over 1,800 pricing and packaging changes across 500 SaaS companies in a single year, averaging 3.6 changes per company. Each one looked small on its own: a new discount tier, an added usage cap, a special rate carved out for one enterprise account that really wanted the deal. But every change is another conditional bolted onto the last one, and conditionals pile up quietly until the engineers who wrote the original logic have moved to other teams, or other companies entirely.

Fifty billing rules and five hundred are not the same problem. Not even close. At small scale, a hardcoded system is annoying, but someone can still hold the whole thing in their head. Past a certain point it becomes what practitioners call pricing logic sprawl, and the damage isn't only technical. Finance looks at the invoice, product looks at usage data, sales looks at the quote, and engineering looks at entitlement flags, and none of these four views agree, because they come from systems that were never built to reconcile with each other. Untangling one disputed invoice can mean pulling numbers from three or four places by hand, on a Friday, while the customer waits on the other end of an email thread.

Algolia is a clean example of this playing out in public. The company built its billing in-house, and the codebase grew complex enough that a routine pricing change needed coordination across teams, up to and including the CEO and CFO weighing in on what should have been minor. Nobody there wrote bad code. This is just what happens, structurally, when hardcoded logic runs into real growth. The only open question was ever when it would show up, not whether.

How SaaS pricing models have shifted toward structures hardcoded logic can't handle

Usage-based pricing went from a niche experiment to the industry standard in about five years, which is fast even by software's standards. The share of SaaS companies using some form of usage-based pricing rose from 30% in 2019 to 85% by 2024, and 77% of the largest software companies now build consumption-based pricing into their revenue model. Revenera's Monetization Monitor found 59% of software companies expect usage-based approaches to take a bigger share of revenue in 2025, up 18 points from 2023. That's most of an industry rewriting how it sells, in under a decade.

Hybrid pricing, some blend of subscription and usage, is where most of that growth actually lands, and it's also the hardest structure to hardcode. Maxio's 2025 SaaS Pricing Trends Report found hybrid models post the highest median growth rate at 21%, ahead of pure subscription and pure usage-based approaches alike. Hybrid isn't one model, though; it's a different combination for nearly every customer segment, often negotiated line by line in a contract, and each combination needs its own rating logic. In a hardcoded system, the number of code paths grows combinatorially with the number of customer arrangements, not linearly. That math catches up with teams faster than anyone plans for.

AI products push this further than anything before them. Bessemer Venture Partners' 2025 Cloud Index found AI-native SaaS companies spend 22% of revenue on compute, versus 8% for traditional SaaS, a cost structure that all but forces pricing tied to variable consumption instead of seats. Bessemer also found 44% of SaaS companies now charge separately for AI features, and among those, 31% use hybrid pricing and 11% go fully usage-based. Credit and token models bill at a granularity, per API call, per token, per agent action, that flat-rate billing infrastructure was never built to track. It wasn't designed to count that finely, because nobody needed it to. Until suddenly everyone did.

Outcome-based pricing adds one more wrinkle on top of that. Zendesk only charges when a support ticket is fully resolved by AI, and getting there meant writing detailed, per-customer documentation defining what "resolved" actually means, which sounds simple until you sit down and try to write it yourself. Intercom prices its Fin product at $0.99 per successful resolution, defined by customer confirmation or by the customer exiting the flow without escalating to a human. Each of these is a custom rule negotiated per contract, and trying to manage that in application code, at any real scale, just doesn't work.

What hardcoded billing logic actually costs when a pricing change lands

The visible symptom shows up first: a rate change that should take an afternoon turns into a two-week project. When billing logic is scattered across application code, a metering service, a CPQ tool, and a pile of reconciliation spreadsheets, changing one price means touching all of them, in the right order, without breaking anything downstream. Every one of those changes carries deployment risk, and a billing bug that ships to production can mean under-billing thousands of customers before anyone catches it.

The deeper cost is that engineering becomes the gatekeeper for every pricing idea a company has. A product manager can't test a new tier without filing a ticket and waiting for a sprint slot to open, and finance can't adjust a discount structure without engineering time it probably doesn't have to spare. Pricing quietly turns into a decision made once and left alone, not because that's the strategy anyone chose on purpose, but because changing it costs more than leaving it broken does.

Finance absorbs a recurring tax on top of all this. When billing logic sits apart from usage data, the first week of every month becomes manual reconciliation across systems that don't talk to each other. Silent overages slip through, aggregation windows don't line up, duplicate events get billed twice because nothing enforced idempotency upstream, and someone catches that by hand, if they catch it at all. At 3.6 pricing changes per company per year, this isn't an occasional fire drill. It's a standing appointment on somebody's calendar, every month, indefinitely.

The biggest cost is probably the one that never shows up on a sprint board: the pricing experiments that never get run because the engineering lift is too high to justify, and the revenue left sitting on the table when a better discount structure can't ship fast enough to close a deal waiting in the pipeline right now.

How a pricing rule engine separates billing logic from application code

A pricing engine, put plainly, is software that calculates prices by applying configurable rules to inputs like quantity, customer segment, contract terms, and live usage data. For SaaS billing specifically, its job is to rate usage, track subscription changes, and turn all of it into accurate line items on an invoice. Configurable is the word that matters here: rate tiers, volume discounts, and promotional credits stop being lines of code and become settings someone changes in an admin panel, no engineer required.

That creates a real architectural split. The rule engine sits between the event stream and the invoice, so "what happened," the metered events, is decoupled from "what it costs," the pricing rules applied to those events. A pricing change happens at the rule layer and never touches application code or triggers a deployment. The application calls the engine to get a price back; the pricing logic itself lives somewhere else entirely.

That split gives a clean answer for what lives where. Tier definitions, volume thresholds, commit drawdown logic, discount stacking, credit burn rates, and per-customer overrides belong in the rule layer. Event emission, authentication, and feature gating stay in application code, because those change when the product changes, not when someone in finance wants to run a new promotion next quarter.

This is exactly what makes hybrid and credit-based pricing manageable instead of brittle. A customer on an annual commit draws down usage against that commit, overage gets rated at a separate tier once the commit runs out, and a mid-contract upsell adjusts the commit amount, all as rule changes rather than new code paths written from scratch. Credit balance checks can happen in real time at the entitlement layer, instead of getting reconciled after the invoice already went out and the damage is done. None of this replaces event ingestion, metering, or invoice generation on its own. The rule engine is one piece slotting into a pipeline that has to work end to end or none of it matters.

The metering infrastructure a rule engine depends on, and why it can't be an afterthought

Metered billing is a different engineering problem than flat-rate billing. Flat-rate billing needs a contract and a monthly invoice run; metered billing needs an instrumented product, an event stream that doesn't drop data under load, and a system that can turn raw usage into an accurate charge at whatever scale the product actually runs at. A popular API product can throw off millions of events per second, and that's a load most in-house systems were never designed to carry.

Four layers have to work together for any of this to hold up: event ingestion, aggregation, rating, and invoicing. A rule engine lives at the rating layer, but if ingestion drops events under load, or aggregation windows don't align with billing periods, or invoicing can't consume what the rule engine produces, the accuracy of the rating logic stops mattering at all. A pipeline built to handle a million events a day won't necessarily handle a hundred million, and scaling each layer is its own separate engineering problem. Treating all four as one problem is how these systems fail, usually quietly, usually for months before anyone notices anything is wrong.

Idempotency and deduplication sound unglamorous, but they're what stands between a billing system and double-charging customers. Queue-based systems buffer events during traffic spikes, which is good, except retries after a spike create duplicate events if nothing catches them first. That has to be enforced at the ingestion gateway, not patched in later inside application code as an afterthought. Some dedicated metering platforms run a 35-day deduplication window specifically so retries can happen safely, without every client team writing custom guard logic against double-counting.

Late-arriving events cause a related headache. A billing event that shows up after its aggregation window has closed leads straight to disputes and under-billing, and there's no clean fix except designing for it from the start. The full trail, from raw event to billable line item to final invoice, needs to be stored and queryable. In regulated industries that's a contractual and legal obligation, not a nice-to-have, and teams that build a rule engine and stop there have solved the logic problem while leaving the data problem exactly where it was.

What changes operationally when pricing rules become configuration rather than code

Product teams get to run pricing experiments without waiting on engineering at all. A new tier, a promotional credit bundle, a discount for one segment: these become configuration changes a product manager ships directly, same day if needed. Pricing becomes something go-to-market moves at its own speed, instead of something stuck behind a sprint queue for two weeks at a time.

Finance gets invoices that are right the first time, and books close faster because of it. When billing logic lives in one rule engine fed by a reliable event stream, invoice generation becomes deterministic: same inputs, same output, every time, without a human checking the math by hand. Month-end reconciliation shrinks from a week of manual cross-checking down to handling the rare, genuine exception.

Engineering stops being on call for billing, which matters more than it sounds like it should. When pricing logic sits outside the application, a pricing change doesn't need a deployment, and a billing error doesn't mean someone gets paged at 11pm to dig through code that has nothing to do with the actual bug. The team that built the product stops moonlighting as the team maintaining a pricing spreadsheet on the side.

Everyone ends up looking at the same numbers, too. A centralized rule engine with a queryable audit trail means finance, product, and engineering pull from one source instead of four, so a disputed invoice gets resolved by checking one system rather than reconciling three of them against each other by hand. Most AI companies that launched with usage-based pricing have adjusted the model at least once since. Teams running a rule engine absorb that as a config update. Teams still on hardcoded logic absorb it as a full engineering project, again.

Where the build-vs-buy decision actually sits for pricing rule engine infrastructure

Building in-house looks better on paper than it turns out to be in practice, almost every time. Early on it offers full control, no outside dependency, tight integration with the existing codebase. What that early estimate misses is everything that isn't the rating logic itself: idempotency, deduplication, late events, an audit trail, tenant isolation, entitlement enforcement. Each of those is its own engineering surface, and each one adds to the maintenance load, month after month, quietly, until it isn't quiet anymore.

The real cost is opportunity cost. Every hour an engineer spends keeping the billing system alive is an hour not spent on the product customers actually pay for. In-house billing systems rarely stay maintained in any real sense; they stay running, which asks much less of a team than maintaining does. As pricing gets more complex, more hybrid models, more per-customer overrides, commit drawdowns, credit burn tracking, the internal system needs constant rework instead of a five-minute config change.

Purpose-built billing infrastructure covers ground that internal builds usually never get to. Real-time credit balance tracking and millisecond-level usage checks matter a lot for AI products, and most in-house systems were built for periodic billing cycles, not that. SOC 2 Type II compliance, an audit-ready event trail, and the option to deploy on-premises are real requirements for enterprise deals, and building all of that internally adds months to a project that was supposed to save time in the first place. Holding sub-50ms P99 latency while processing billions of API requests a month takes dedicated infrastructure investment most product teams can't justify building themselves.

Flexprice is one option built for exactly the problems this piece has walked through: hybrid pricing, credit and token billing, AI products that need entitlement checks in real time. It handles metering, entitlement enforcement, invoice generation, and revenue reporting in one platform, available as a cloud service or deployed on-premises for companies that need that. Build, buy, or something in between, the decision should rest on where pricing complexity is headed over the next two or three years, not on where it happens to sit today.