That was the core theme of our final panel from the Monetizing AI Summit hosted by Schematic — where Shar (ex-Stripe, now leading billing at Vercel) and Ben (our co-founder & the CTO at Schematic) broke down the biggest blockers to pricing agility, why AI is forcing SaaS teams to rethink their billing infra, and how to build systems that scale alongside your product.
If you’re still treating pricing as a once-a-year conversation… or your team groans every time someone suggests a pricing change… this one’s for you.
You’ll learn:
Why pricing agility is no longer optional in the AI era
The 4 bottlenecks that stall most pricing changes (and how to avoid them)
A practical architecture for entitlements, usage transparency, and single source of truth pricing
How embedded UIs and decoupled billing systems massively reduce dev cycles
What metrics actually tell you whether your billing architecture is working
This is your blueprint to build (or rebuild) pricing and billing with flexibility, speed, and scale in mind... so you can ship faster, monetize smarter, and stay competitive in a world where AI is rewriting the playbook.
Watch the full session, then forward it to your head of engineering or product team. They’ll thank you later.
Fynn Glover: At Automox, I owned pricing from roughly $10M to $40M ARR. Every pricing change took a two-quarter engineering sprint. That pain is why we started Schematic. A mentor once said, price is a number, pricing is an architecture. Tonight, Ben Papillon (co-founder and CTO, Schematic) and Shar Dara (ex-Stripe, now leading billing at Vercel) will dig into how to architect billing for flexibility in a fast AI market.
Shar: Traditional SaaS could update pricing once a year. That does not work now.
AI pushes usage, tokens, credits, outcome models. You must adapt faster.
Product velocity has increased. You need to monetize new surface area quickly.
At Vercel we average 5–6 pricing changes per month across SKUs, add-ons, and packaging.
Ben: Seat pricing is falling. Usage, credits, and outcomes are rising. Those models are more complex to implement. Agility is now a capability, not a nice to have.
1) Multiple sources of truth
PLG stack has one catalog. Sales stack adds CPQ with its own catalog. Spend alerts invent a third.
Result: sync work, incidents, and blocked model changes if one system cannot represent the new meter.
2) Weak usage and cost observability
Customers need real-time usage and cost, self-serve.
Enterprises need exports or APIs for finance systems.
Without a single endpoint for usage and cost, you end up stitching data and creating delays.
3) Entitlements coupled to plans
Hardcoded if plan X then feature Y does not scale.
Sales overrides in CRM for enterprises while PLG entitlements live in product. Now you have two truths.
4) Fragmented UX flows
Add-ons, trials, and checkout built differently by each team.
Every change requires bespoke engineering and slows rollouts.
A) Single source of truth for pricing
Make your PLG catalog the canonical source. Sales and CPQ read from it.
New price types appear once and propagate everywhere.
B) One endpoint for usage and cost
Build or adopt a service that aggregates meters and calculates cost.
Power the product’s usage UI and a public export/API from the same source.
C) Decouple entitlements from pricing What to require from your entitlement system:
Features independent from price. Reprice without rewriting feature gates.
Admin overrides. GTM and finance can grant exceptions.
Separate entitlement cycle from billing cycle. Early access before invoice.
Audit logs. Who changed what and when.
D) Standardize the UI layer
Use embedded UIs and SDKs for plans, add-ons, payment, and usage displays.
Reduce custom front-end work per change.
Ben: Treat entitlements as its own service. Two core domains:
Customer profile. Integrated view of subscription, usage, allocations, rollovers.
Product catalog. Plans, features, prices, legacy status, availability by channel.
Three interface groups must be first class:
Applications
Access checks via feature flags.
Usage events for meters.
Drop-in components to display balances and invoices, including legacy logic.
Internal operators
UI inside the tools they live in (CRM, admin) for overrides, grants, and migrations.
Other systems
Webhooks or RPC for finance, alerts, and data pipelines.
Goal: All commercial logic lives behind the service rather than scattered through the app.
// Pseudocode for the idea, not a library const { enabled, usage, allocation } = useEntitlement("report-generation"); if (!enabled) return <UpgradePrompt />; runReport(); trackUsage("report-generation", 1);
The absence of plan checks in app code is the point. Change plans and packaging without rewriting product logic.
Shar’s three signals:
Time to ship a pricing change. Measure in days. Healthy target is under a week.
Billing reliability. Uptime near 99.99%. Lower indicates infra risk.
Ticket volume. Track the share tied to billing, pricing, and payments.
Data stack and CPQ
Not solved. Expect fragmentation.
Own a centralized pricing and entitlement truth.
Warehouse everything if you must, but prefer platforms with strong opinions and integrated CPQ to reduce glue code.
Unbundled vs all-in-one
Future skews unbundled. Pick best-in-class for entitlements, tax, invoicing.
Tradeoff is data fragmentation. Solve with your central entitlement and pricing layer.
Why not just “billing does it all”
Billing tools optimize for finance workflows. Entitlements are invasive to product and must guarantee users get what they paid for at runtime.
Embedded UIs
Shar: the future is embedded UIs. You should build product, not rebuild billing surfaces.
Shar: Pricing agility is mandatory. Invest in a single source of truth, strong usage and cost visibility, and decoupled entitlements.
Ben: Build primitives that hide commercial complexity from app code. That is how you change pricing in days, not quarters.