{"slug": "extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale", "title": "Extend or replace – how to evaluate your billing stack at AI scale", "summary": "Based on the article, the author, who previously led billing at a global streaming company, argues that billing complexity compounds invisibly over time as new features are added, forcing engineering teams to spend most of their effort on maintenance rather than innovation. The article provides a framework for evaluating whether to extend or replace an existing billing stack, emphasizing that this is a critical and expensive decision that becomes more difficult the longer it is delayed.", "body_md": "I wish someone had written this post for me five years ago when I was running billing at a global streaming company.\nIt 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.\nThe monetization team was 14 engineers.\nWe 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.\nThen a second checkout flow.\nThen gift cards.\nThen, “credits” (think Audible’s credits).\nEach 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.\nI left that world and spent years helping AI companies figure out monetization (first when I cofounded Paid, now at Solvimon). 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.\nHowever, the billing sprawl looks the same every time.\nIf 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:\nDo you extend what exists, or replace it?\nThis 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.\nHere’s my framework which I wish I had earlier:\nWhat you inherited\nBefore we get into the assessment, let’s look at what a typical AI billing stack looks like from above.\nThis is an incredibly simplified version of a billing system handling 3 types of customer flows.\nEach 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.\nAt 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). A payment middleware layer handling orchestration, refunds, and payouts.\nWhen you have a simple PLG flow, that’s not a problem. When you’re handling 160,000 combinations and channels, things get complicated.\nEvery block represented code. Every piece of code represented an engineer who wasn’t building product.\nWhy companies build billing system – and why it works for a while\nI need to be honest here, because the “just buy something” take is too simple.\nThe “just code it yourself” is very enticing, especially with AI. Building your own billing DOES give you real advantages:\n- 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.\n- 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.\n- No vendor dependency. There’s a legitimate argument that billing is too critical to outsource to a vendor who might change their API, raise prices, or get acquired like Metronome.\nThese are real and I’d never tell someone they were wrong for building.\nNo, I’m lying – I would. These advantages are front-loaded but the costs only come by later.\nWithin a year of having our own billing system, it was already 50%/50% buillding/maintaining and by the second year it was already 80% maintenance and just keeping the lights on. That is keeping tax codes updated, edge cases, and cross-system reconciliation.\nWhat started as a superpower became handcuffs that I felt completely trapped in. Every change required four teams. Yes, the commercial teams could deploy new pricing – but that required a specialist helping them 100% of the time because there were simply too many systems to check.\nSound familiar? It should. Add proration, tax handling across markets, customer hierarchy, revenue recognition – each one that was manageable alone will eat your time and frustrate the organization.\n6 questions to diagnose your monetization stack\nThese are the questions I wish someone had given me before I spent two years extending a system that had already hit its ceiling.\nI’ve gone through RFPs and RFCs, so I can be trusted.\n1. Where does pricing logic live?\nWhere are the pricing calculations?\nIf they’re scattered across microservices, embedded in API middleware, hardcoded in config files you DEFINITELY have an orchestration problem.\nAre they on the website, in pricing pages, in the CRM, in the ERP, and in the data warehouse too?\nIf every new pricing model means touching application code – you need to change something.\nAt the streaming company I was at, pricing logic lived in at least four places: the billing platform, the subscription middleware, the market-specific based product catalog, in the Google Play and App Stores, plus a set of business rules that determined what combinations were allowed.\nChanging a price in Norway meant updating three systems and hoping the fourth didn’t break at month-close with the ERP.\nTest yourself: If pricing logic lives in your billing system as configuration, you have room to extend. If it lives in code wrapped around your billing system, you’ve already outgrown it.\n2. How many systems does a single invoice touch?\nTrace the path from “customer uses the product” to “customer receives an invoice” – count the systems – all of them.\nMetering, rating, billing, tax, payment processor, ERP, CRM, commercial website, app, entitlements…\nIf the answer is 5+, your orchestration code is probably growing with every product line and market that you add.\nWhen companies tell me they’re on Stripe – I find that they’re usually on Stripe + a custom entitlements service + a metering pipeline + a reconciliation script + a spreadsheet at the very least. Yes, Stripe handles the payments fine. The problem is the code you write around it, meaning the layer that connects 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.\nI, too, learned that the hard way when going through a big audit.\n3. Can any product team ship something “paid” without creating more work for you?\nThis was the test we always failed. Country managers wanted to run a promotional bundle. If it fit within the terms pre-defined years ago – that was fine. For anything else – it required changes to the product catalog, the subscription middleware, the entitlement overrides, and the billing calculations, the checkout pages, and synchronization between 3 teams, four tickets, and at least 4 days of work.\nIf your product org needs billing engineering every time they want to put a price tag on a feature, you’re rate-limiting your own monetization.\nAt AI companies shipping weekly and sometimes daily, this adds up fast.\n4. What happens when a self-serve customer wants an enterprise contract?\nThis is where most AI billing stacks don’t really work well.\nNearly 100% of people I talk to have a manual process for this. That’s OK when you’re small. Your self-serve runs through Stripe, enterprise runs through Salesforce CPQ, or worse, a spreadsheet and a Slack thread with finance.\nTwo billing workflows, two data models, one finance team trying to reconcile them at month-end and figure out what was actually billed, what should be billed, and what the customer got (This also hurts customer support!).\nIf the answer is “we manually migrate them to a different billing flow”, you’ve definitely found the ceiling. I call this “Billing v1”.\nExtending a PLG billing stack to handle SLG doesn’t work by adding more code around it. The architecture needs to support both motions in one ledger – what I’ll call “Billing v2”.\n5. How long does it take to close the books?\nIf the close cycle is 2 weeks, finance will start having problems. When finance is spending those 2 weeks reconciling billing data against revenue recognition against the ERP, because each system has a slightly different version of reality – that’s a real problem.\nAsk your finance team where the time goes. If the answer is “figuring out discrepancies between systems” – you can’t extend your system any further. The discrepancies exist because the systems are separate.\n(And if you think revenue recognition is simple, here’s my favourite PDF – a 64 page set of IFRS-15 rules.)\n6. Can you change pricing without an engineering sprint?\nAI pricing moves fast. Credit exchange rates between models. New usage tiers. Committed spend discounts. Restructuring how you bundle inference and fine-tuning.\nTest it as concretely as you can: how fast could you roll out a 20% discount for annual commits on your mid-tier plan?\nAnd I don’t mean just in the billing system – I mean on pricing pages, in dashboards, in the revrec, in the CRM… If the answer involves engineers, a staging environment, and a deploy pipeline you’re looking at the ceiling.\nScore yourself\nEstimating the real cost\nBe honest here, because most build-vs-buy analyses compare the wrong things. You end up comparing feature-sets and the “contract cost” vs engineering salaries and call it a day.\nI firmly believe that misses most of the actual cost on both sides.\nThe cost of extending\nDirect FTE cost. Count the engineers who spend >50% of their time on billing. At some companies hiring senior engineers for billing, the salaries are $300-450K fully loaded, meaning a 3-person billing team is $900K-$1.35M/year.\nAt the streaming company, our 14-person team was upwards of $1.5M annually and that was in a lower-cost market!\nOpportunity cost. This one is really hard so no-one does the math. My 14 engineers could’ve been focusing on higher-growth initiatives. Those 3 engineers you’re hiring for billing could be building product, improving inference, shipping integrations that drive revenue with partners.\nAt a company growing 3x YoY, the compounding opportunity cost of an engineer maintaining billing code is enormous.\nCoordination cost. Every pricing change that requires cross-team work has a cost: meetings, tickets, QA, staged rollout, rollback plan.\nAt the streaming company, a simple bundle change consumed 40+ person-hours across four teams. Multiply by the amount of pricing changes per quarter.\nRevenue leakage. Systems with manual reconciliation leak. 1-3% is common in companies with complex billing. On $10M ARR, that’s $100-300K/year you’re not collecting.\nClose cycle cost. A 2-week close means your finance team spends half its time on reconciliation. It also means decisions based on data that’s 2-6 weeks old.\nYou may not care, but the finance team DEFINITELY does.\nTotal: $1.5M-$3M+/year at AI-scale companies, but it grows with every product line.\nThe cost of replacing\nPlatform subscription. Billing infrastructure platforms (Solvimon, Orb, Lago, Zuora, Paddle, Recurly – depending on your needs) typically charge based on transaction volume or revenue processed. For an AI company at $5-50M ARR, expect $50K-300K/year.", "url": "https://wpnews.pro/news/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale", "canonical_source": "https://arnon.dk/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale/", "published_at": "2026-03-15 21:38:13+00:00", "updated_at": "2026-05-22 16:12:10.126213+00:00", "lang": "en", "topics": ["startups", "enterprise-software", "artificial-intelligence"], "entities": ["Solvimon", "Paid", "Audible", "Play Store", "App Store"], "alternates": {"html": "https://wpnews.pro/news/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale", "markdown": "https://wpnews.pro/news/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale.md", "text": "https://wpnews.pro/news/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale.txt", "jsonld": "https://wpnews.pro/news/extend-or-replace-how-to-evaluate-your-billing-stack-at-ai-scale.jsonld"}}