When we think about pricing, it’s easy to focus on the numbers. In practice, the real limitation is the architecture underneath. If every change requires weeks of engineering work, it doesn’t matter how good your idea is, you won’t move fast enough.
That mattered less when SaaS was mostly seat based. Teams were growing, so revenue scaled with headcount, and pricing could sit still for a year at a time. For AI products, costs are variable, value is tied to usage, and new features ship quickly. The world has changed and how we approach pricing needs to change too.
At Schematic’s Monetizing AI Summit, Shar Dara (Vercel) and I co-presented a talk about how we see the future of billing. I wanted to capture our key ideas here.
Seat-based pricing worked in the ZIRP years because marginal costs were low and headcount always grew. More hires meant more seats, which meant predictable revenue growth without touching pricing. That model breaks down when growth isn’t tied to hiring.
AI products flipped this. Costs track usage, not seats, and can this can grow even when teams stay flat. While powerful, usage-based pricing is hard to get right and requires consistent iteration. Shar described what this looks like in practice at Vercel: “We launched a lot of pricing changes. I think we have an average of five to six pricing changes per month, and those include things like new SKUs, add-ons or packaging changes.”
This level of iteration is becoming common in startups and estabilished companies alike. Pricing agility is no longer a nice-to-have. It’s a requirement for any company trying to compete in AI.
The first blocker is multiple sources of truth. A self-serve product store plan data in the application database, while enterprise deals are managed from Salesforce or a CPQ tool. Customer success might hand out per-customer plan overrides. Sales might customize terms for a single customer. The result is the same: no single place to see what’s supposed to be true, and no reliable way to keep it in sync.
The second is usage and cost visibility. Customers expect to know what they’ve been charged for and why. That usually means a usage page for self-serve, and exports or APIs for enterprise. "The main scalability issue I’ve seen is just being able to get real-time data… a single endpoint that actually spits out cost and usage." (Shar)
The third is the growing complexity of pricing plans. At first, they’re simple, like "The Pro plan gets Feature X.” Over time, they become complex rules like "The Pro plan gets 5,000 credits a month, limited to 500 a day, and can buy extra for $5 per 100, but can’t exceed 10,000 without upgrading to the enterprise plan.” That complexity is hard to manage when pricing logic is scattered across the codebase. "The last thing you want to get wrong is when someone goes to use the product, they get what they paid for."
The fourth is UX flow, and how it often is implemented differently by different teams. Shar commented: "If there’s no standardized way to actually implement [add-ons, trials, checkout], different product teams or different engineers would end up actually just building the add-on on the self-serve flow in a different way. That becomes hectic to scale over time." That inconsistency makes the product harder to use and harder to maintain. It also makes small pricing changes slow, because each one requires dev work and prioritization.
The first principle is unified pricing data. One source of truth across both PLG and sales-led motions avoids sync issues and supports new pricing models. Shar said it best, "The solution to the multiple pricing problem is being intentional with a source of truth for your pricing... Just keeping a single source of truth is always the way to go."
The second is unified usage and cost data. Shar explained how Vercel rebuilt their reporting layer: “Behind [our usage page], there’s a single endpoint that you can call to get both the usage and cost for a customer… that did not exist before.” That single endpoint reduced confusion for customers and overhead for finance.
The third is decoupling entitlements from pricing. Entitlements are the commercial relationship between a customer and a feature. They should live in a dedicated service. That service should manage both the customer profile (subscriptions, usage) and the product catalog (plans, features, prices).
Finally, standardize how billing surfaces in the product. SDKs and drop-in UI components help avoid one-off implementations and make new pricing models easier to ship. Keeping pricing standardized across your product avoids a common pitfall we see when the "UI layer [becomes] a real slowdown… you could be spending six sprints to do a $10 price change."
Putting it all together, “You want a system with many different interfaces. Good UI for business users, event-based usage tracking for developers, drop-in components for end users. All backed by a single source of truth.”
The simplest measure is speed. How long does it take to make a pricing change? Shar was direct: “It should not take over a week or few days.” This is critical to ensure pricing changes support revenue growth, not impair it.
The second is reliability. Users should always see accurate, up-to-date usage and cost data. If reporting lags or looks inconsistent, trust erodes quickly. That means your billing system has to deliver consistent data across dashboards, exports, and APIs.
Finally, look at support load. If a large share of tickets are billing-related, that's a problem. Customers should be able to self-serve the answer to simple questions relating to usage, cost, and payments. The goal isn’t to eliminate every edge case, but the bulk of questions should be answered directly in-product. When billing is working well, support should handle exceptions, not explain invoices.
Pricing agility has shifted from a concern of large enterprises to a requirement for everyone. The architecture you put in place determines how fast you can move.
Unifying pricing data, unifying cost and usage data, and decoupling entitlements from pricing are the core capabilities to build toward. With those pieces in place, companies of any size can adapt their pricing at the pace the new AI-powered market demands.
