확장 또는 교체 – AI 규모로 청구 스택을 평가하는 방법

[Skip to content](https://arnon.dk/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale/#wp--skip-link--target) [Arnon Shimoni](https://arnon.dk) * [About Arnon](https://arnon.dk/about/) * [Now](https://arnon.dk/now/)  # Extend or replace – how to evaluate your billing stack at AI scale I wish someone had written this post for me five years ago when I was running billing at a global streaming company. It was my first B2C company – 29 or so markets, 209 active price points and thousands of active discount campaigns. We had country managers who needed pricing changes live across our own system, Play Store and App Store all at once. **The monetization team was 14 engineers.** We started with a reasonable setup – a billing platform, a subscription middleware layer, some custom orchestration to handle market-specific logic. It worked. Over time, bundles were added, campaigns to allow trials with market-specific phases, then partner integrations with different revenue shares and activation models. Then a second checkout flow. Then gift cards. Then, “credits” (think Audible’s credits). Each addition made sense when proposed but together, they created a system where those 14 engineers spent most of their time maintaining the glue between systems instead of building anything new. **Billing complexity compounds in a way that’s invisible until you’re already deep in it** , and I’m afraid not many people get that. I left that world and spent years helping AI companies figure out monetization ([first when I cofounded Paid](https://www.eu-startups.com/2025/03/paid-raises-e10-million-to-transform-ai-agent-economy-and-launch-beta-programme/), now [at Solvimon](https://solvimon.com)). Between the two, the architecture is different, but the pattern is very similar: credits instead of gift cards, and model-based exchange rates instead of seat-based pricing. Usage metering instead of subscription phases. However, the billing sprawl looks the same every time. If you just joined a company to own billing, or you’re an engineer who’s been handed the billing platform you’re about to face the same fork in the road: **Do you extend what exists, or replace it?** This is the most expensive decision you’ll make in your first year. The longer you wait with this decision, the more difficult it gets down the line. Here’s _my framework_ which I wish I had earlier: ## What you inherited Before we get into the assessment, let’s look at what a typical AI billing stack looks like from above. This is an incredibly simplified version of a billing system handling 3 types of customer flows. _Billing sprawl is a real problem._ Each block often connects to more than just one other system, and that’s custom code that someone has to maintain. Each block is MULTIPLE failure points. Each of these is a reason why a month-end close cycle takes 2 weeks instead of 2 days. At the streaming company, our version of this diagram had even more boxes. Subscription middleware translating between channels and the billing platform. A separate entitlements service with its own override logic (I’ve written [about why you need that separation before](https://arnon.dk/why-you-should-separate-your-billing-from-entitlement/)). A payment middleware layer handling orchestration, refunds, and payouts. When you have a simple PLG flow, that’s not a problem. When you’re handling 160,000 combinations and channels, things get complicated. _This is a real example of a B2C company’s monetization levers, with 160,000 combinations that needed routine testing._ Every block represented code. Every piece of code represented an engineer who wasn’t building product. ## Why companies build billing system – and why it works for a while I need to be honest here, because the “just buy something” take is too simple. The “just code it yourself” is very enticing, especially with AI. Building your own billing DOES give you real advantages: 1. **Total control over business logic.** At the streaming company, our market-specific pricing rules were genuinely unusual. Trials that varied by country. Bundle structures that changed quarterly. Partner revenue shares with custom splits. No off-the-shelf billing platform in 2018 could handle all of it. Building gave us the flexibility to model exactly what the business needed. 2. **Deep integration with the core product.** Entitlement checks happened in-line. No latency from external API calls. No sync issues between “what the billing system thinks” and “what the product actually delivers.” When you own the code, you can make billing invisible to the user. 3. **No vendor dependency.** There’s a legitimate argument that