Your pricing page is the roadmap
Seats, events, and AI credits quietly became plan walls, and those walls now decide what products can do, so the pricing page is the roadmap.
Bob Bass
There is a fresher way to read a company than its changelog: read the pricing page. The rows are annotations on the product explaining who it is for, what it will let them do, and which behaviors the company withholds until you cross into a bigger plan. Somewhere in the last decade the pricing page stopped being arithmetic and became the roadmap, enforced not by a planning document but by gates and counters written into the application. Packaging quietly became the most senior product team in the building, without anyone announcing it.
What product-led growth did to packaging
Packaging used to live in the contract. Enterprise software moved through a funnel that took months: a demo, a security review, a negotiation, and a signature bundling features into editions decided at the end. The pricing page was a formality trailing behind the order form.
Product-led growth inverted that funnel, and it forced packaging into the app itself: sign up first, get value without talking to anyone, and upgrade without a procurement cycle. A free tier had to exist in code, and limits had to be evaluated while people use the thing.
Usage-based pricing grew up alongside for a reason: meters that track something customers recognize as their own value make self-serve fair, and one page can carry a small account next to a large one. The trouble is what the meter does next: once the meter is the revenue engine, every feature must be meterable, gatable, and attributable to a plan, and anything that resists gets redesigned until it does not.
When the billing wall becomes the architecture
The clearest case study is the seat. Per-seat pricing suits collaboration products, so it became the default, and then the wall started reorganizing behavior on both sides of it. Teams under the wall invented workarounds, shared logins among them, and products answered with roles whose primary purpose is the meter: read-only access kept free to defuse the workaround, guest access throttled by packaging rather than by collaboration design.
Event-based meters do the same thing to data models. A meter needs a definition of what an event is, so products get designed to produce events that meter cleanly: an action that used to fire three ambiguous increments gets rebuilt as one. Rate limits move into the request path, allowed-integration counts get hard-coded, and the schema accretes columns whose only reader is the billing job.
AI credits are the newest version and the most revealing. Every vendor shipping model features had to invent a unit for that spend and an exchange rate (a chat reply costs this many, an image that many), so features are costed before they are designed. Interfaces warn mid-task that an action will consume credits, and defaults get pushed toward cheap paths. The meter became a budget for the product team as much as a price for the customer.
Walls like these are also self-fortifying: once behavior exists to satisfy a plan limit, removing the limit is a revenue decision, and the contortion becomes permanent architecture. The roadmap splits into the one the team believes in and the one the plan walls require, and those are rarely the same document.
Reading a page like a roadmap
The pricing page also tells you what a company believes about its own business. A seat wall that covers viewers says collaboration is the conversion lever. An event meter says your throughput does their price discovery. An AI credit balance with a published exchange rate says, plainly, that the company does not yet know what each action costs it, so the variance is yours. A free tier with generous limits and one guarded door says someone upstairs watches a conversion number, and the list behind that door is the real roadmap.
None of that is an insult, and the legibility is a service: a customer can find where a product wants them stuck before getting stuck. It also explains a plan sheet's oddities, where a wall that looks arbitrary (three integrations on the middle plan, five on the next) usually traces back to a packaging decision that was never written down anywhere else.
What a sane tier looks like
Most of what makes pricing feel hostile is not the amount but the invisibility of the walls and the arbitrariness of their shapes. The tiers that age well meter one or two things the customer already thinks of as their own volume: people for a collaboration tool, records for a CRM, runs for an automation tool. A meter the customer can simulate in their head is the one that renews.
They tier by scale rather than by decency. A wall around how much you can do is defensible; a wall around security basics or the ability to work together at all is how a company ends up in the workaround economy, training its customers in its least secure habits.
They also warn before they bill, since an overage that surprises in month eight gets disputed in month nine. And they upgrade on growth rather than on bait: the pitch for a bigger plan is that you will use more of what you already use, not that something you rely on moved upstairs.
The teams that get this right treat packaging as product design with a scoreboard attached, and they write the walls down deliberately instead of letting them accrete. It is the least glamorous revenue work in software, and it should share the table with product, not own the roadmap outright.
From the desk that wrote this
This blog is run by the team behind Layerbase, so every post comes with a conflict of interest attached rather than concealed behind it.