Build vs. Buy: Why Engineers Struggle with Billing Infrastructure

The first version of a billing infrastructure system is easy to build. It’s the second and third versions, the ones built under pressure, that cost the most. This article breaks down why that cycle happens and how to think about the decision before you’re already in it.

Build vs. buy: Why the first billing system always works

The first version of a billing infrastructure system almost always works. It’s usually simple:

• A few subscription plans
• A Stripe integration for payments
• Some database tables to track customers and subscriptions
• Middleware that checks plan access before serving requests

At this stage, building in-house makes sense. The system is small, and pricing is simple. But billing infrastructure rarely stays that way. After a few product launches, the system must support changes:

Each new requirement adds another layer of logic. Pricing also changes frequently. Across 500 SaaS companies, analysts tracked more than 1,800 pricing and packaging changes in a single year, an average of 3.6 per company.

This is when the build vs. buy question becomes real. The system that worked at launch now carries more responsibility than it was designed for.

Why is billing infrastructure harder than it looks?

Billing infrastructure is harder than it looks because it’s not one system. It’s a chain of interconnected problems, and here is where each one shows up.

1. Billing infrastructure covers more ground than most teams expect

Billing is not just invoicing, and that misconception is exactly where most teams run into trouble. What you are actually dealing with is an entire revenue workflow: contract management, pricing and packaging, usage metering, feature access, invoice generation, payment processing, and revenue recognition. 

Billing systems typically handle invoices and payments. While some, like Stripe, do offer basic feature flags, they do not offer metered quotas, governance controls, or real-time enforcement. That responsibility falls to entitlements, the rules that define what customers can use and how much they can consume. 

For example, a free user gets 10 API calls per day, and a Pro user gets unlimited access. Infrastructure like Stigg’s manages the entitlements layer so pricing and product access stay aligned.

2. The complexity compounds fast

Most teams assume billing infrastructure gets complicated eventually. What they do not expect is how fast that happens, or how many different directions the complexity comes from at once.

Dates

Subscriptions run on billing periods, which means someone has to make a decision early: does billing start on signup, or on the first of the month? What happens in February? What about leap years?

These questions sound trivial, but changing billing period logic after launch generates customer support tickets and requires careful data migration. It’s not a decision you want to revisit.

Upgrades and downgrades

Moving a customer from plan A to plan B mid-cycle forces hard questions. Do you prorate? Issue a credit? What if they are on an annual plan, switching to monthly?

Every edge case has to be handled in code, and every pricing change you make multiplies those edge cases.

Usage-based billing

Deduplicating users, tracking events at scale, resetting counters each billing period, computing time-based charges down to the second: this is not a weekend project. 

For instance, Algolia built its billing system in-house and paid for it at scale. The codebase grew so complex that nearly every pricing change required cross-team coordination across engineering, finance, and the executive layer, including the CEO and CFO.

Idempotency

This is where many billing infrastructure systems fail quietly. A billing event that fails and gets replayed cannot charge the customer twice, and maintaining that guarantee across retries and failures is harder than it sounds at high volume.

Taxes

Tax logic depends on what you sell, where you are incorporated, and where your customer is located. Across 100+ countries, it becomes a tree of conditional logic that changes on a regular basis.

Dunning

Payment failures require retry logic, invoice reconciliation, access revocation, and customer email workflows. Each one is a separate system to build and maintain, and teams almost always underestimate this one.

None of these layers exists in isolation. Each one compounds the others, and the teams that feel it most are the ones who did not see it coming.

3. Billing infrastructure doesn't cover product access

Here is something most engineering teams discover later than they should: Billing handles money, but it does not handle product access. Those are two different problems, and conflating them is where things start to get messy.

Entitlements are the commercial allowances that define what a customer can actually do inside your product based on their plan. In practice, that looks something like this:

• A free user gets 20 API calls per day and sees a paywall on export features
• A Pro user gets 5,000 API calls and access to all standard features
• An enterprise team gets SSO, a dedicated support tier, and configurable data retention

These rules have to live somewhere. Billing infrastructure tools like Stripe, Zuora, and Orb are built to handle invoicing, payment processing, and revenue recognition. They are not built to enforce feature access at the product level. That enforcement has to live “somewhere else,” and that somewhere else is almost always the in-house system no one wants to touch.

4. Grandfathering accumulates silently

Every pricing change creates a new customer cohort, and the customers on the old plan stay on it. Nobody notices at first because it feels like the right thing to do for existing customers. Three pricing changes in, you are looking at something like this:

• Cohort 1: original pricing, grandfathered indefinitely
• Cohort 2: first pricing change, partial feature set
• Cohort 3: second pricing change, different usage limits
• Cohort 4: current plan

Every new change has to account for every cohort that came before it, and that list only ever grows in one direction. What looked manageable at launch becomes a liability every time the pricing team wants to run an experiment.

5. AI and usage-based pricing raise the stakes further

AI features change the nature of the problem. Every LLM call has a real marginal cost, which means billing infrastructure now has to track consumption accurately enough to protect margins, not just generate invoices. That’s a meaningfully different job. Seat-based SaaS billing can afford some imprecision. AI billing cannot. 

Credit systems introduce a layer that most in-house billing infrastructure was never designed for. Companies selling AI features need:

• Preloaded balances
• A ledger that tracks spend in real time for revenue recognition and auditability
• Hard enforcement logic that stops a single power user from exhausting a balance before the billing period resets

Usage governance compounds this issue further. At the enterprise level, teams need to:

• Allocate credits across departments 
• Set spend limits per team or project
• Give customers self-serve visibility into consumption before they hit a wall

Most in-house billing infrastructure gives customers no visibility into where they stand until they hit a wall. That produces two failure modes: runaway usage that quietly erodes margins, or blunt cutoffs that generate support tickets. 

Neither is acceptable at enterprise scale, and retrofitting governance onto a system that was designed for flat subscriptions is one of the more expensive rebuilds a platform engineering team can take on.

The build vs. buy decision

Every team eventually hits the point where its billing infrastructure cannot keep up. That’s when the build vs. buy question stops being theoretical and starts having a deadline attached to it.

Where most teams get this wrong

Most teams do not ask the build vs. buy question until they are already under pressure. A pricing change needs to ship in six weeks, the in-house system cannot support it, and engineering is now making an infrastructure decision with a deadline attached.

That pressure changes everything. There is no time to evaluate options properly, so the team patches the existing system and takes on more technical debt. The teams that get this right are the ones who asked the question early, before the urgency hit, when they still had the space to make a deliberate decision.

The real cost of building billing infrastructure

The first version of an in-house billing infrastructure takes a week to build. A few tables, some feature flags, and middleware to check access before rendering a component. At 50 employees, it works fine.

At 500, that same system is now managing:

• Legacy plans from three years ago
• Grandfathered pricing for early customers
• Usage limits across five products
• A tech stack inherited from two acquisitions

The system that took a week to build now requires a dedicated team to maintain. Rebuilding it takes months, and teams often build the wrong thing because requirements shift mid-build. That’s not just engineering time. It’s every sprint not spent on features that customers actually pay for.

When building in-house makes sense

Building makes sense in specific situations, and it’s worth being honest about what those situations actually are:

Companies like Netflix built custom billing systems, but that decision came after reaching a scale where it made economic sense. Most engineering teams are not in that position.

The right questions to ask before deciding

Before making the call on billing infrastructure, these are the questions that actually matter:

• Can your existing billing infrastructure support the next pricing change? If the answer is no, the conversation is already urgent.
• How often does pricing change? Teams that experiment with pricing every quarter need billing infrastructure that can move at that pace. Custom systems rarely can.
• How many billing providers do you need to support? Companies mid-migration between Zuora and Stripe, or running multiple billing systems after an acquisition, need an abstraction layer that custom billing infrastructure struggles to provide.
• Who owns entitlements today? If the answer is "a database someone built three years ago," that system will break the next time the product catalog changes.
• What is the actual engineering cost? A net-new billing infrastructure system takes months to build, and even when teams get there, it’s often the wrong solution.

What you are actually buying

A commercial solution handles the edge cases your team has not hit yet, so you do not have to. Things like upgrade and downgrade logic, proration, grandfathering, multi-currency, tax handling, and dunning flows are already solved.

The speed argument is where it gets compelling:

Billing infrastructure also touches the CRM, CPQ, ERP, and data pipelines. Each connection is another place where data can go out of sync. A commercial solution with native integrations reduces that surface significantly, and that alone is often worth it.

Billing infrastructure is bigger than the billing problem

The build vs. buy decision is about the full billing infrastructure stack: the product catalog, entitlement rules, the metering layer, and the billing integration.

Teams that only evaluate billing software often miss the systems that create the most engineering work later.

If you’re working through this decision, these are the problems most teams are trying to solve:

• Pricing changes require engineering sprints because plan logic and access rules are hardcoded.
• Usage-based pricing adds complexity with event tracking, metering, and billing period resets.
• Grandfathered plans accumulate over time, creating multiple cohorts with different logic.
• Product access rules live in fragile in-house systems that break when the product catalog evolves.
• Billing migrations become risky, especially when moving between systems like Zuora and Stripe.

Teams that map these layers early make better infrastructure decisions than teams that treat billing as an invoicing problem.

If any of these sound familiar, see how teams like Miro and Webflow handled it, without rebuilding from scratch.

FAQs

1. What is billing infrastructure?

Billing infrastructure is the technical stack that manages how a company charges customers, tracks usage, controls feature access, and recognizes revenue. It includes the product catalog, entitlement rules, metering layer, payment processing, and integrations with systems like CRM and ERP.

2. Can Stripe handle all of your billing infrastructure needs?

No, Stripe handles payment processing, invoicing, and tax compliance, but it does not manage product access or entitlements. Companies that need feature gating, usage governance, or credit-based pricing require an entitlements layer on top of Stripe, not instead of it.

3. How long does it take to build billing infrastructure in-house?

A basic billing infrastructure takes days to weeks to build, but a production-ready system that handles upgrades, downgrades, usage metering, grandfathering, and entitlements typically takes 3 to 6 months. Most teams underestimate this timeline because edge cases multiply as soon as real customers and pricing changes are introduced.

4. What is the difference between billing and entitlements?

The main difference between billing and entitlements is that billing handles money after the purchase decision, while entitlements control what a customer can access inside the product based on their plan. Billing generates invoices and processes payments. Entitlements enforce feature limits, usage caps, and access rules in real time.

5. What are the signs your billing infrastructure needs to be replaced?

The clearest signs are that every pricing change requires an engineering sprint, your team is maintaining multiple plan cohorts with different logic, or your system cannot support usage-based or credit models without a rebuild. If the pricing team is regularly blocked by engineering, the billing infrastructure has become a bottleneck.