Arnon's right; mess = coupling. Billing systems couple things together that business models eventually force apart. The fragmentation problem is the result of the coupling: When a system can’t decouple what a deal requires, teams pull concerns out and handle them in reasonable ways given their current priorities. That’s how entitlement/proration/etc logic ends up in feature flags, product code, etc. My ever-evolving mental model of a billing system is four things: 1. Catalog + Contracts, 2. Invoicing + Payments, 3. Entitlements + Metering, 4. Reporting + Accounting. Each one decoupled from the rest. Stigg and Schematic are great; they decouple #2 from the rest giving operators more flexibility. But catalog+contracts and entitlements+metering move into their platform still coupled, and reporting+accounting still doesn't have a great story. (I haven't done deep integrations with either, so please excuse any oversimplifications/errors here.) If you want experiment velocity (among other things), my opinion is that there needs to be a small pricing kernel that sits in the middle of those four concerns; a shared source of truth that each specialized concern reads from and writes to. (disclaimer: I'm a builder in this space too)

One of the biggest challenges I experienced was trustworthy, point‑in‑time cohorting and orchestration - in a multi‑month repackaging + price increase, almost every incident traced back to not being able to reliably identify, freeze, and track who should be touched at each step (eligibility → notification → migration → etc). A few example issues that we encountered: - We couldn’t programmatically surface which accounts had early‑day “handshake” promises (evergreen pricing/grandfathering). Out of caution, we excluded broad swaths of customers—even though only a small % actually had exceptions. - We didn't have a reliable, standardized way to ensure that all customers getting repriced had been notified on time with respect to each country's regulations. - Customers initially selected for repricing needed late-stage exemptions (e.g. had started renewal discussions with sales team, their usage patterns had changed, etc). We lacked a clean way to “unwind” those selections—even after notifications were sent. - Selection → execution drift: by the time the actual migrations came, account states had changed. Without point‑in‑time snapshots, cohorts silently mutated and the wrong customers were touched.

@Rob Litterst Outside billing platform, but it's tricky, since these migrations rely on input from multiple systems that aren't usually hooked together. You need usage/adoption data, structured contracts (if you have them), billing data (current plan, etc), customer demographics attributes, etc, and you need to make changes to the billing platform, internal customer database, create notifications/messages, and more. So if I had a magic wand, we would've had all of the necessary data at our fingertips without error-prone sql queries in a thin orchestration system that sat outside of/on top of existing billing, crm, internal, etc. systems.

Agreed! I really enjoyed the insight from Ulrik as well as the perspectives and knowledge from others on the call - super helpful, ty ty!

@Rob Litterst Thanks!

😀