I ran billing at a global streaming company with nearly 30 markets, 200+ price points, and 14 engineers on the billing team. We spent 18 months extending a system that had already hit its architectural ceiling. By the end we'd built billing v1.5: too customized to maintain, too patched to scale, and unfortunately too entangled to replace cleanly. The 14-engineer team was still 14 engineers.

I've since had this conversation with dozens of AI companies. The architecture is different with credits instead of gift cards, model-based exchange rates instead of market pricing, usage metering instead of subscription phases, but overall still the pattern is identical. Billing complexity compounds invisibly until you're deep in it.

If you're evaluating your billing stack right now, here's the framework I wish someone had given me.

The architecture you probably have

Each block and set of lines is custom code someone maintains and a failure point - but because these aren't one system, you have to maintain the glue logic between them too.

When companies tell me they're on Stripe, they're usually on Stripe plus a custom entitlements service, a metering pipeline, a reconciliation script, and a spreadsheet. Stripe handles the payments fine. The problem is the layer connecting Stripe to your pricing logic, your entitlements, your usage data, and your finance team's close process. That layer is your actual billing system. You just don't call it that.

6 questions to diagnose your stack

Run through these as honestly as you can:

1. Where does pricing logic live? If it's scattered across microservices and config files rather than centralized as configuration, every pricing change is a deploy. You have an orchestration problem, not a billing problem.

2. How many systems does a single invoice touch? Trace the path from usage to invoice. If it crosses four or more systems connected by custom scripts, your orchestration code is growing with every product line you add.

3. Can a product team ship something paid without opening a billing ticket? At the streaming company, a promotional bundle required four teams, four tickets, and four weeks. If your product org needs billing engineering every time they put a price tag on something, you're rate-limiting your own monetization.

4. What happens when a self-serve customer wants an enterprise contract? If the answer is "we manually migrate them to a different billing flow," you've found the ceiling. PLG and SLG need to live in one ledger.

5. How long does it take to close the books? Two-week close cycles aren't a finance problem. They're a data integrity problem caused by billing, revenue, and contract data living in different systems.

6. Can you change pricing without an engineering sprint? Credit exchange rates, usage tiers, committed spend discounts: if each one requires an engineering project, you're slowing down every commercial decision.

Score yourself: 0 to 1 red flags means extending is probably fine. Two or three puts you in a grey zone where each extension makes the eventual replacement harder. Four or more means the architecture has hit its ceiling.

The real cost of each path

Most build-vs-buy analyses compare the wrong things. Here's what extending and replacing actually cost at AI-scale companies.

The math isn't close - and the challenge isn't simply the cost - but the risk of the migration. Because migration is a one-time cost however, extending is permanent, and it compounds.

How Solvimon is built around these problems

Each of the six diagnostic questions maps directly to an architectural decision we made when building Solvimon.

Pricing as configuration, not code. Rate cards, tiered pricing, per-customer overrides, credit exchange rates are all managed through the API or UI without deploys or engineering tickets. This is where Solvimon diverges from Stripe Billing. Stripe gives you prices and subscriptions. Solvimon gives you a rate card engine where committed spend, overage, credits, and per-customer negotiated rates are configuration, not workarounds buried in Stripe metadata. At the streaming company, changing a price meant updating three systems. In Solvimon it's a rate card update, and engineering doesn't need to be in the room.

One system, one ledger. Solvimon consolidates the core billing lifecycle with product catalog, metering, rating, credit ledger, invoicing, entitlements, and revenue data all in one platform. You still integrate with payment providers, tax engines, and your ERP, but these are clean integrations rather than orchestration code. The difference between the old state and the new state isn't fewer boxes. It's fewer arrows. When the core billing logic lives in one system, the orchestration code disappears because the complexity moved from your codebase into infrastructure designed to handle it.

PLG and SLG in one ledger. Self-serve customers convert through hosted checkout. Enterprise customers get custom rate cards, committed spend agreements, and negotiated terms all in the same system, on the same customer record. When a self-serve customer raises their hand for an annual commitment, the transition is a configuration change: update the terms, apply a custom rate card, set up committed spend tracking. No data migration. Solvimon's founders built Adyen's billing engine, which handled merchants from single-store to global enterprise on one platform. The PLG-to-SLG path isn't a feature that was added later. It's how the architecture was designed from the start.

Credit architecture that's actually architecture. Not Stripe's gift card workaround. Solvimon gives you composable credit primitives: wallets, burn-down tracking, pooled organizational credits, and exchange rates between models. When a customer buys 10,000 credits and those credits burn at different rates for GPT-4, image generation, and fine-tuning, that's a ledger design problem. Most billing systems treat it as an afterthought. Solvimon treats credits as first-class objects because AI pricing demands it.

Usage metering with real-time visibility. Consumption data can't be a batch job at month-end. Solvimon meters usage in real-time so you can enforce entitlements based on live consumption, surface alerts to customers, and calculate billing continuously. This also unlocks per-customer margin visibility by matching inference costs to revenue at the customer level. You know which customers are profitable and which are underwater, something most billing systems can't tell you.

Revenue integrity by default. Billing events, revenue data, and ledger entries live in the same system. When an invoice generates, the revenue implications are already calculated with no reconciliation step between what you billed and what you recognize. Immutable ledger entries, full event history, every change traceable, and not a feature you enable later but a core property of the ledger itself. Companies we work with went from two-week close cycles to two or three days, not because their finance teams got faster, but because the reconciliation work disappeared.

What migration looks like with Solvimon

The scariest part of replacing a billing system isn't cost. It's the migration itself. In practice, this is what the timeline looks like.

Total engineering investment is two to four months. After that, ongoing billing engineering drops to near zero. The 14-engineer problem becomes a half-person maintenance task.

The extension trap you'd want to avoid

The crossover happens around month 9 - before that, extending looks cheaper. After that point, the gap only widens because every extension adds orchestration code, and orchestration code compounds. The credit system you bolt on today becomes the integration you maintain forever. The reconciliation script you write this quarter becomes the process nobody touches next year.

The decision

Is your billing system's architecture capable of handling your pricing complexity in 18 months? Not today — today it's manageable. The question is whether the structural decisions in your current stack are sound for where you're heading: how it handles credits, how it connects PLG to SLG, how it feeds revenue recognition, how fast pricing can change.

If yes, extend. Not every billing system needs replacing.

If no, the cheapest time to act is now.

We built the billing engine behind $1.1T (€970B+) in annual volume at Adyen. We know exactly when billing breaks and what to build instead.

If you're evaluating your stack, start with an architecture conversation, not a demo - arnon.shimoni@solvimon.com