Last week I did an office hours session with Rob from PricingSaaS and Ulrik Lehrskov-Schmidt from Willingness to Pay. The topic was pricing iteration, why most companies do so little of it.

We look at why companies like Vercel can ship 6+ pricing changes in a single month earlier in 2026, while at the same time Cursor reset its core plan twice in 2025, adjusting credit-to-output ratios within days of OpenAI and Anthropic moving token prices.

You wouldn't be wrong to think these companies are smart, but they're not smarter than you - just faster at it. There really isn't much of a difference between them and everyone else, but if you don't do anything - it will look like it because pricing velocity does compound.

What compounding pricing changes looks like

If your billing system lets you make changes (and your org lets you ship it) - you will learn something at each step of the way.

Could be that a new tier converts much better, and it may look like customers actually care about the units you picked!

If you increase pricing, you'll learn how elastic a segment is to a, say, 12% price increase.

So I'd ask:

1. When did you last change how much you charge?

2. When did you last change what you charge for?

It's obvious that companies that change pricing once a year get one data point a year to compare. But it's also then clear that companies that can run a pricing experiment every few weeks get dozens. Think about having 40 points vs just two.

That means you're not guessing, you just have better evidence.

When pricing changes are easy, you make more of them. When you make more of them, you learn faster.

It sounds obvious. It isn't, because so many companies have made pricing changes expensive to execute, and expensive things happen less often, and then the org loses the muscle for it entirely.

Plus, lots of companies end up doing the same sequence:

Two forces that kill velocity

Ulrik and I mapped two forces that create this drag.

The system

Your billing infrastructure defines the ceiling of what's technically possible to price. I see a pattern I call the "NIH" cycle: a team builds their billing, gets good at it, and then the system starts defining the pricing instead of the other way around. The constraints start to feel like common sense. Nobody questions them. By the end, the company is optimizing around what the stack can do instead of what the market wants.

The NIH cycle operates in a single, rigid direction: you build a system, master its intricacies, and eventually let that system dictate the boundaries of your pricing. As the pricing team adapts to these constraints, the limitations begin to feel normal - you get tunnel vision. Over time these barriers go unquestioned, and the focus is inwards and not outwards.

Underneath that cycle is one person that is very commonly an engineer who built the integration to a 3rd party billing system and that person becomes the gatekeeper for every pricing change. It's fine to trust what you understand, you understand what you built, and your first instinct when someone proposes replacing it is skepticism. That means then that the ceiling on your pricing is what that person can imagine, and what they can imagine is bounded by what they already built.

But let me also tell you, if you think you can just keep hacking around Stripe or you can vibe-code your own billing system - it really isn't that easy.

Think you can now tell Claude Code "write me a billing engine that handles this use case" and it will produce something plausible in an afternoon? Plausible is the worst possible output here, and it makes the trap deeper than it was, because the thing that used to cost you two weeks and some thought now costs you an afternoon and a whole bunch of tokens, but let me tell you there's a serious Dunning-Kruger effect running right now… And I'd note that it's funny because dunning is also on that list and it's a billing term. Which is kinda my point. Billing isn't a CRUD app.

The org

It's also natural that sales teams cut bespoke deals to close quarters. Each deal adds variance to the contract book and bespoke deals "privatize" the upside to the rep while forcing the the operational cost across the entire company. Product teams can delay monetization to accommodate exceptions, RevOps is forced to build shadow spreadsheets, and the brunt of it is on CS that inherits having to deal with this and make sure companies are happy when their invoices are, inevitably, wrong.

The deeper the commercial debt, the harder it becomes to make a uniform pricing change, because fewer customers share the same terms.

That's why I said this during the office hours:

Read that again! Your billing system isn't a system for charging customers. It's a system for remembering every promise you've ever made.

This happens often when SLG and PLG aren't run on the same system.

The system and The org often feed each other and complicate things. A rigid billing stack limits what you can offer and a messy contract book and deal desk approvals forces more custom logic back into the system. Fix one and you're still stuck on the other.

What's worth evaluating

A diagnostic from the session that I think is worth taking back to your team:

Could you run one pricing experiment this month that would have taken a quarter a year ago?

If not, try to figure out which force is the reason. Is it the system (you can't technically represent the change)? Is it the org (too many stakeholders, too much commercial debt to move uniformly)? Or is it the person (one engineer's calendar/prio is the bottleneck)?

All three are fixable if you are dedicated enough. You don't need better pricing or strategy consultants to make this work.

This post is a follow-up to PricingSaaS Office Hours on pricing iteration, featuring Ulrik Lehrskov-Schmidt (Willingness to Pay) and Arnon Shimoni (Solvimon).