Why Your Pricing Changes Take Quarters Instead of Hours
The four-pillar architecture behind companies like Vercel, Clay, and Supabase that ship pricing changes in hours, not quarters.
Hey, Paweł here.
Unless you’ve been living under a rock, you’ve noticed the PM role is expanding. At every company I’ve advised, I’ve watched PMs become increasingly responsible for driving business outcomes — not just shipping features.
AI accelerates this: as time spent on Jira, PRDs, and standups compresses, what remains is the work that actually moves revenue. Pricing and monetization sit at the center of that shift.
I experienced this firsthand at Ideals — the best company I ever worked for. We had current plans, newer plan versions, and historical plans where customers were being migrated over time. The logic of what each customer can do and see lived in the source code.
A single pricing change triggered changes across many systems, required close collaboration across multiple teams, and testing across all plan types and user roles. Everything worked, but each change was a company-level effort, not something a single team could handle.
The insight that stayed with me: what would really help is decoupling entitlements and features from the source code — separating what a customer can access from the implementation that enforces it. That’s the core principle this article teaches.
The vision: instead of pricing changes being organization-wide efforts, PMs can experiment with packaging as comfortably as they’d run any other product experiment — without generating work for other teams, without the QA burden. Pricing iteration at the speed of product iteration.
The thesis is simple: pricing should live in config, not code. Defined once, inherited everywhere — from the pricing page to the billing system to the feature gate in your code.
I wrote this piece with Fynn Glover, founder & CEO of Schematic and author of the The Pricing Playbook for AI & SaaS — with contributors from Superhuman, Stripe, Cursor, Vercel, and Supabase. Fynn has worked with teams at Zep, Plotly, and Automox, and interviewed pricing leaders at Vercel, Notion, Calendly, and Salesloft. The framework, case studies, and pricing stories here are his — told in his voice.
Hey, Fynn here.
Vercel ships five to six pricing changes per month. Most companies ship one or two per year — and each one takes a quarter of engineering time.
Last year I sat in a pricing review where the team had a brilliant idea: move three features from Enterprise to Pro, add a usage cap on API calls, launch an add-on for analytics.
The strategy was sound. Data supported it. Everyone agreed.
Then engineering said: “That’s a quarter of work.”
I’ve seen this at dozens of companies I’ve worked with. The pricing strategy takes a week. The pricing change takes a quarter. By the time it ships, the market has moved.
This isn’t a strategy problem. It’s an architecture problem. And this post is the blueprint for fixing it.
What You’ll Learn
This is a deep dive into the architecture that separates companies shipping pricing changes in hours from those stuck in quarterly cycles:
The three failures that compound — when your pricing architecture is broken, and why AI makes the urgency real
The four pillars of monetization architecture — unified catalog, decoupled entitlements, real-time metering, and a control plane — with PM tests for whether yours is broken
Decoupled entitlements in practice — real production code showing what it looks like when pricing lives in config, not code
Three case studies — Zep (trial to production in 4 days), Plotly (two AI products, two quarters faster), Automox (pricing paralysis to 75% faster launches)
The monthly pricing meeting — 2 hours, 4 blocks, copy-paste ready — the operating system for making pricing a function, not a project
Build vs. buy matrix — and an honest “when you don’t need this” section
1. The Three Failures That Compound
When I ask founders where their monetization bottleneck is, they blame their billing tool or their CPQ (configure-price-quote tool). They’re pointing at the symptom, not the cause. In reality, they have a pricing architecture problem. It shows up in three ways:
The strategic failure. You’re leaving money on the table. Most companies review pricing once a year. Your product ships features monthly, costs change quarterly, competitors adjust continuously.
The operational failure. No owner, no cadence, no muscle. It looks like the “pricing committee” meeting — VPs of Product, Sales, Marketing, and Finance gather for a three-hour debate. Everyone has an opinion. No one has the autonomy to make a decision. The default answer is “let’s do nothing for now.” Justin Talerico, CEO of Automox, described delaying pricing and packaging work for two years — despite having a strong pricing analysis — because they couldn’t action the recommended changes in the product.
The architectural failure. Even when you have the right strategy and the will to act, your codebase won’t let you. R&D teams pour millions into “Monetization Plumbing” that delivers zero core product value. Jalal Iftikhar, who leads Business Technology at Notion, puts it sharply: “Usage-based billing systems are designed to consume events from products to then inform invoices. They’re not designed to enable the commercial tinkering on pricing & packaging that drives growth.”
At my last company, the monetization stack was a complex web of disconnected product catalogs, multiple billing & quoting systems, hard-coded entitlements, and homegrown metering — Stripe, NetSuite, Amplitude, Salesforce, Salesforce CPQ, a homegrown metering system nobody trusted, and Gainsight. Eight systems.
Count how many of these you recognize in your own stack. Most Series B+ companies are running some version of this — a half-dozen disconnected systems, each a different source of truth for a different team. Thousands of lines of hard-coded billing logic. Different teams thought they were managing monetization, but in reality, no one owned it. No one could own it.
One tier launch took six months. An add-on initiative was abandoned entirely.
The truth hiding inside most fast-growing companies: pricing agility = revenue agility, and hard-coded pricing and billing logic is the choke point.
Fix the architecture, and the other two failures become solvable. Making pricing a function — not a project — requires one owner, one cadence, one set of metrics. Later in this article, the monthly pricing meeting format gives you the exact operating system for this.
2. The Compounding Cost of Inaction
Even when the math is clear, most teams still can’t act. The board pushes to raise prices. The team knows the product is worth more than two years ago. But fear of churn paralyzes the decision.
I lay out a simple comparison in my book. Imagine a company at $10M ARR (annual recurring revenue) with 200 customers. Two paths:
Path 1: Price Lift. Raise prices 20%. Even with 4% churn, the net result: $1.6M in new ARR.
Path 2: The “Safe” Add-On. Launch a $10K/year add-on. Sell to 25% of your base. Result: $500K in new ARR. No churn — but one-third the impact.
The $1.1M gap isn’t a one-year number. That higher price becomes the new baseline. Every renewal, every expansion dollar compounds on top of it. At 7% annual growth, that initial 28% lift turns into roughly 39% uplift within five years.
Superhuman waited six years to raise from $30 to $40. One decision. 4% churn. 28% overnight lift. The compounding effect will reshape their revenue curve for years.
As Justin Gagnon, who leads Growth Engineering at Calendly, puts it: “Monetization should be a first-class citizen as early as humanly possible... If you don’t get it right early, you’re paying down your bad decisions late. And when you’re paying down bad monetization decisions, it’s way more expensive than paying down other bad decisions.”
This is why pricing inaction is the most expensive decision most companies make — and why the architecture that enables fast, confident pricing changes is the highest-leverage investment you’re not making.
3. Why AI Changes the Equation
AI is making this worse — and if you’re a PM shipping AI features, you’re feeling it already. Traditional SaaS has deterministic costs: a user creates a project, you know what it costs to serve. AI workloads are probabilistic. A query might cost $0.001 or $0.50 depending on context length, model choice, and retry logic. Gross margins can swing from 90% to below 50%.
Kyle Poyar (Growth Unhinged) calls it the pricing reformation: with AI, undercharging can make customers unprofitable. The biggest players are experimenting in public, changing pricing monthly. The hybrid future — platform fees plus usage, seats plus credits, consumption plus pay-as-you-go — demands architecture that can handle it.
Shar Dara puts it plainly: “Billing was hard, and is hard still. Historically, traditional SaaS businesses were able to get away with updating pricing every year or so, but that just can’t cut it anymore. Pricing changes cannot be on the back burner with AI in the mix.”
The companies winning — Vercel, Clay, Supabase — treat pricing as a continuous function. Test Monday, measure Wednesday, roll back Friday. That speed is an architecture capability, not a strategy one.
4. The Four Pillars of Monetization Architecture
So what does a pricing architecture that actually works look like? The clearest framework I’ve seen comes from Shar Dara, who leads billing at Vercel, and Ben Papillon, Schematic’s CTO — presented at the Monetizing AI Summit.
Shar opened bluntly: “Traditional SaaS could update pricing once a year. In the AI era, that’s impossible. At Vercel, we average five to six pricing changes per month — new SKUs, add-ons, packaging tweaks. You need architecture that can keep up.”
Ben added: “If pricing agility is important, you need an architecture that lets you change how you price without rewriting your product.”
Together they mapped the four biggest blockers:
multiple sources of truth (PLG (product-led growth) stack, SLG (sales-led growth) stack, CPQ (configure-price-quote) tools — each storing its own prices)
SKU sprawl (too many product variants to track)
hard-coded entitlements — access rules controlling what each customer can do — scattered through the code (
if plan x...metastasizing everywhere)inconsistent UX across checkout and upgrade flows.
Their answer: a unified, four-layer architecture:
The diagram below shows how these pillars connect in practice — plan subscription, entitlement checking, and usage tracking all flowing through a central platform:
Pillar 1: Unified Product Catalog
A single schema describing every plan, feature, entitlement, and price. It’s the canonical source for billing, provisioning, analytics, and go-to-market (GTM). When product and billing share one catalog, new SKUs appear everywhere instantly.
Shar summed up the source-of-truth problem: “If you don’t define a single source of truth early, you end up with incidents every time you change price.”
PM test: Can marketing update the pricing page and have it reflected in what customers get — without an engineering ticket?
Pillar 2: Decoupled Entitlements
The heart of it. Entitlements are the rules that control what each customer can access in your product: Can this user use feature X? How many seats do they get? Can they create more projects? Every SaaS product enforces these rules — but most hardcode them, scattering access logic across the codebase.
In practice, feature access falls into three categories:
Boolean features are the simplest — a customer either has access or they don’t. SSO, advanced reporting, a specific AI model. On or off, determined by plan.
Trait-based features enforce allocation limits — the numbers on your pricing page. Seats, projects, teams. These define what a company has. When you check “Can this user create another project?” you’re checking a trait against a limit.
Event-based features enforce consumption limits — API calls made, tokens consumed, storage used. These track what a company does. When you check “Has this user exceeded their monthly API limit?” you’re checking cumulative events against a cap.
Most teams hardcode all three types — and that’s where pricing changes become engineering projects.
The fix: decouple that logic from code. Store feature access rules centrally and query them at runtime.
Instead of this, repeated for every feature and plan:
if (planId == Plans.Enterprise) {
enable_feature_x();
} else if (planId == Plans.Pro) {
// ...
}Your code becomes a single, clean call:
const { enabled } = useEntitlement("reports");
if (enabled) {
showReportButton();
}As Ben Papillon puts it: “Entitlements start as a pebble in your shoe and become cement around your feet. You can’t move.”
The architecture also eliminates a hidden performance cost. Traditional entitlement checks add 50-100ms latency per API call and create a single point of failure.
A streaming approach changes the game: entitlement state is streamed on startup and maintained continuously. Every check becomes a local memory read — latency disappears. If the entitlement service goes down, your app keeps running with last known state. For customers, this means instant feature access. For engineering, it means one less thing that can break at 2am.
Traditional entitlement checks (50-100ms latency) vs. Streaming approach (no latency)
PM test: Can a non-engineer move a feature from Pro to Enterprise — or change a seat limit — without a code deploy?
Pillar 3: Real-Time Metering
AI workloads generate probabilistic consumption. Real-time metering gives customers transparency and finance predictability.
This is critical because, as Marcos Rivera of Pricing I/O describes: “The ‘oh shit’ moment everyone’s worried about is that huge, unpredictable bill. It’s nerve-wracking to go into an agreement and not know how much you’re going to use. Real CFOs don’t buy that way.”
Your architecture must solve this anxiety. That means three things:
Event ingestion at scale. Every billable action — API calls, tokens consumed, compute minutes — gets tracked the moment it happens. Not batched overnight. Not reconciled at month-end. Real-time.
Usage tied to billing periods. Metering without context is just a counter. Good metering knows that a customer’s “month” runs from their signup date (say, March 15 to April 14), not the calendar month. It tracks consumption against their specific allocation and resets automatically.
Exposure to both sides. Customers see usage against their limit — before the surprise invoice. Sales sees a customer approaching their cap — before they churn. Finance sees margin data in real time — before the quarterly surprise. Same data, different views, one truth.
Tools like Schematic, Metronome, and Orb handle event ingestion, period-aware aggregation, and real-time usage APIs out of the box. Building this in-house is a common source of “metering debt” that quietly eats engineering quarters.
PM test: Can a customer see usage against their limit before the surprise invoice? Can sales see a customer approaching their cap before they churn?
Pillar 4: A Control Plane for Product Teams
Let non-engineers manage monetization. This is the layer that turns the other three pillars from an engineering tool into a business capability.
Here’s what it looks like in practice: your head of growth wants to test whether doubling the free tier’s API limit increases conversion. Without a control plane, that’s an engineering ticket, a sprint planning discussion, a code change, a deploy, and a rollback plan. Two weeks minimum. With a control plane, they log into a dashboard, change the limit from 1,000 to 2,000, and it’s live. If conversions drop, they revert in 30 seconds.
The same applies to sales. An enterprise prospect wants a custom package — 500 seats, unlimited projects, a higher API cap. Instead of filing a ticket and waiting for eng to create a custom plan, sales configures it directly and sends the proposal the same day.
A good control plane provides: plan and SKU creation, limit and tier adjustments, entitlement overrides for specific customers, experiment management, and full audit logs so everyone knows what changed, when, and why.
PM test: Can you launch a pricing experiment this week — not “get approval,” actually launch?
—
These four pillars aren’t independent — they’re layers. The catalog defines what exists. Entitlements control who gets what. Metering tracks how much they use. The control plane lets your team manage all three without engineering. Break one layer and the others compensate poorly. Build all four and pricing becomes a continuous function.
5. Decoupled Entitlements in Practice
To see what this looks like in practice, here’s a real example using Schematic’s React SDK — a single component that handles entitlement checking, loading states, usage limits, and feature gating. The pattern is the same regardless of which entitlement platform you use: replace hundreds of lines of plan-checking logic with a single hook:
This is real production code. Centralized entitlement checks work like feature flags, but for billing logic. You can display UI conditionally based on usage and limits, and surface usage and allocation data to end users — all from a single hook.
The entitlements system supports overrides, grants, scheduled access, and revocation — all managed by Product, Finance, and GTM teams through the control plane, with full audit logs:
This simple pattern replaces hundreds of lines of brittle logic. It also allows business users to change packaging without touching code.
6. Before and After Decoupling Entitlements
7. When You Don’t Need This
One plan, no usage component — Stripe + hardcoded checks are fine.
Pure per-seat — skip metering. Start with entitlements + catalog.
Under 10 people — config file + Slack = your control plane.
Pre-PMF — fix entitlements (Pillar 2) because that’s debt regardless. Don’t build the full stack until pricing is worth iterating on.
Heuristic: if pricing changed fewer than twice last year, you have a strategy problem before an architecture problem.
8. How to Build Monetization Architecture: A 5-Step Roadmap
Step 1: The Entitlements Audit (Weeks 1-2)
Search your codebase for if (plan == ...) and count what you find. That number is your pricing debt. Map which features are gated, how they’re gated, and how many places the logic is duplicated.
Step 2: Extract to a Centralized Service (Weeks 3-4)
Replace hardcoded checks with a single entitlement service your app queries at runtime. Start with Pillar 2 because it’s engineering debt blocking you now — the product catalog (Pillar 1) is a design problem you can solve in parallel. This is where dedicated entitlement platforms come in — tools like Schematic that treat access rules as infrastructure rather than application code.
Step 3: Unify the Product Catalog (Pillar 1)
Single source of truth for plans, features, and prices — independent of Stripe. When product and billing share one schema, new SKUs appear everywhere instantly.
Step 4: Add Metering (Pillar 3)
Only if you have a usage component. Connect events to your catalog so usage flows into billing automatically.
Step 5: Build the Control Plane (Pillar 4)
This is where compounding happens. Non-engineers can now create plans, adjust limits, and run experiments without engineering tickets. Test Monday, measure Wednesday, roll back Friday.
9. Case Studies
Zep — Trial to Production in 4 Days
Zep builds long-term memory for LLMs. Usage unpredictable, metered billing not optional.
Before: lost revenue from untracked usage, frustrated sales team, engineering pulled into billing plumbing.
Timeline:
Day 1: Trial start. Connected Stripe, modeled plans/entitlements.
Day 4: Live in production.
Day 7: Annual plan conversion.
Day 30: All plans on Schematic.
Results: free-to-paid conversions from limit enforcement, proactive sales outreach, engineers back on core product.
Daniel Chalef (founder): “We were able to integrate Schematic into our workflow within a couple of days.”
Plotly — Two AI Products, Two Quarters Faster
Plotly saw the same pattern. When the team decided to launch two AI-powered products, the old approach would have meant parallel billing pipelines, separate entitlement systems, and months of integration work.
With their product catalog and entitlements already modeled centrally, the launch sequence was additive: define the new features, set the usage limits, configure the tiers, and ship.
Both AI products launched two quarters ahead of the previous timeline — not because the team worked faster, but because the architecture didn’t fight them.
Automox — From Pricing Paralysis to 75% Faster Launches
Automox — a mid-market IT management platform backed by Insight Partners and Koch — spent four years deferring pricing changes. Not because they lacked data. They had pricing studies and clear packaging recommendations ready to go. The problem was purely architectural.
Their monetization logic was hardcoded across the application, split between two separate billing systems — one for e-commerce, one for sales-led motions — with entitlements buried in config files. The result: redundant plans, inconsistent customer states, and a three-month minimum lead time for any pricing tier change. Two full-time engineers were consumed just keeping the plumbing running.
Co-founder Jay Prassl called it “pricing and packaging sclerosis.” The CMO put it more bluntly: even when they had data-driven packaging recommendations, they couldn’t act on them. The architecture had become a veto on the business.
The cascade was textbook. Monetization initiatives — new tiers, add-ons, custom configurations — piled up in the backlog. Customers on older plans faced inconsistent feature access and billing visibility issues, driving support load and churn risk. Revenue sat on the table because the systems wouldn’t let anyone pick it up.
After migrating to Schematic, Automox cut time-to-launch for new pricing tiers by 75% and freed two full-time engineers from maintenance work — turning monetization from a blocked backlog item into something they could actually iterate on. Their growth team could now launch, package, meter, and monitor features from one place without constantly involving engineering.
Brian Wleklinski, Senior Manager of Growth & Digital: “Schematic has transformed how we manage our pricing and packaging. The ability to iterate quickly and provide our customers with a seamless experience has been invaluable.”
10. The Monthly Pricing Meeting
This is the section I’d print out and bring to your next leadership meeting. It’s the operating system for the ownership problem. Two hours, once a month, four blocks:
Block 1: Customer Data (30 min). Usage trends, billing data, approaching-limit customers. High usage + low ARPU (average revenue per user) = expansion candidates. Low usage + high ARPU = churn risk.
Block 2: Learnings Scan (30 min). What sales, CS, and finance are hearing. Win/loss patterns. Feature requests tied to pricing friction.
Block 3: Product → Pricing Roadmap Sync (30 min). What’s shipping in the next 30-90 days? Which tier should it live in? Does it shift the value metric? Does it need to be an add-on? Rule: no feature ships without a monetization stance. This prevents “free value leakage.”
Block 4: Conclusions and Decisions (30 min). This meeting only creates leverage if it creates action. Choose 1-3 actions for the next 30 days. Each action must have: an owner, a hypothesis, a timeline, and expected impact.
Key distinction — two speeds: Global changes (new pricing page, tier restructure) are infrequent and high-stakes. Local changes (adjust a limit, test an add-on, run a promotion) should happen continuously. Most of your monthly meeting actions should be local experiments.
Attendees: CEO/CPO, Sales, CS, Finance/RevOps, Marketing, Growth.
Outputs you leave with: A synchronized product + pricing roadmap. A unified view of revenue opportunities and risks. 1-3 local experiments with owners and timelines. A continuously updated pricing backlog.
How to Measure Success
Pricing-change velocity: “should change” to “it’s live.” Target: under 1 week.
Billing uptime: 99.999%.
Billing support tickets: The canary. If you can’t hit those numbers, you don’t have an asset — you have a liability.
11. Build vs. Buy Monetization Architecture
12. Closing
Most founders think about pricing strategy. Almost none think about pricing architecture. But here’s what I keep seeing: your architecture determines your strategy. If your systems can’t move, your pricing can’t move, and your revenue stays stuck.
Kurt Smith, the CEO of Fexa, once said something I find both true and haunting: “Think about all the creative pricing & packaging conversations in SaaS & AI companies that have simply stopped happening, because people have accepted that even if they had good ideas, their systems would make testing those ideas impossible.”
Your architecture doesn’t have to be the reason good pricing ideas die.
You’ve been running the entitlements audit in your head while reading this. Now do it for real. Block 30 minutes this week, search for if (plan ==, and count what you find. That number is your starting point. This article is the blueprint to pay it off.
— Fynn
Thanks for Reading The Product Compass
Hey, Paweł here again. It’s amazing to learn and grow together.
If this surfaced pricing debt you've been ignoring, start here: https://schematichq.com/book (free download)
And consider subscribing, if you haven’t already:
Have a great week ahead!
— Paweł
 | A guest post by
|
Nice! I've been thinking about hybrid pricing ever since I read https://schematichq.com/book - credits can be so hard for buyers to understand, and to tell you what else we like - predictable cost :)) hehe - old habits die fast.