The Pricing Page Said Yes Before the Backend Did

What we shipped

Collimer’s 2026-08 pricing page went live this week: a $99 audit, then Writer at $150, Team at $250 ($200 annual, the featured plan), Studio at $500 founding rate. Every plan on the page says unlimited seats. That line shipped the same day as a fifteen-row comparison matrix, new structured data for every card, and an update to the page’s agent-readable summary so agents reading the page get the same numbers a human would.

Underneath the page, the product’s plan-enforcement code still has a legacy seat-limit field on the old tiers. The new plans don’t self-serve into a seat cap the way the old ones did, because the new plans don’t self-serve at all yet, full stop. Checkout isn’t live. Every one of these plans starts with a mailto conversation. The pricing page is real, the numbers are final, and the enforcement that would make “unlimited seats” true under load hasn’t been written for the new tiers, because nobody has hit them yet.

It’s the same product that, one week earlier, shipped a post about a setting that stayed correct for years and then quietly stopped being true the moment the infrastructure underneath it changed. This week’s gap is the same shape, caught earlier and named on purpose instead of found later.

What broke (or got harder than expected)

Nothing broke. That’s worth saying plainly, because the interesting part of this week wasn’t a bug, it was a choice made in the open about a gap that hadn’t caused a problem yet. The PR that shipped the pricing page didn’t merge quietly. It listed four numbered approval gates in its own description: the ladder itself is now final on merge, the writing feature is being pre-sold via concierge signup before it exists, unlimited seats is published as doctrine while the legacy limiter still exists in code, and a live homepage experiment was deliberately left untouched pending its own conclusion. Every one of those is a decision someone could disagree with. None of them were hidden.

A decision worth naming

The seats claim is the one worth sitting with. “Unlimited seats” reads as a simple fact on a pricing page. It’s actually a bet with a specific, stated reason it’s currently safe: nobody can self-serve into a seat-limited plan today, because signup for every new tier runs through a person, not a form. The gap is real. It’s also currently unreachable, and the PR said exactly why, instead of either hiding the gap or blocking the launch on closing it first.

That’s a different failure mode than the one people usually worry about with AI-assisted shipping velocity. The risk isn’t that a claim gets published without anyone checking it. It’s that the reasoning that made the claim safe on day one quietly stops being true on day forty, and nobody goes back to check the sentence that justified it. A stated gap with a name and a reason is at least a sentence someone can re-read later and ask: is this still right?

There’s a broader thesis underneath that bet, and it’s worth stating plainly: the actual GEO work never waited on the backend. The fifteen-row comparison matrix, the structured data on every plan card, and the updated llms.txt block all shipped the same day as the pricing numbers, and none of it needed a working checkout flow to be true or useful to whatever reads it, human or agent. Good GEO work doesn’t depend on whether you can capture and bill a user yet. It depends on whether the page is legible, current, and citeable right now. The seats claim can wait on a founder call to close. The structured data couldn’t wait, and didn’t. The effort that moves a page’s GEO score is meaningful on its own terms, independent of whether the funnel underneath it can convert anyone today.

What’s next

• Close the legacy seat-limit gate in the plan-enforcement code so the claim and the code agree, rather than continuing to rely on concierge-only signup as the thing standing between the page and the gap.
• Watch the pre-sell decision once the writing feature actually ships. Concierge mailto CTAs make sense while the feature is dark; they stop making sense the moment self-serve exists and customers are still routed through email.
• Let the homepage hero experiment conclude on its own schedule before touching hero copy that could contaminate it.
• Keep shipping GEO surface work (structured data, comparison content, llms.txt updates) on its own schedule. The score-moving effort doesn’t wait for checkout to go live, and neither should we.
• Revisit this alongside the same week’s post on the studio’s pipeline running solo, both are about work shipping with a stated gap named out loud instead of hidden.

What we’re still figuring out

We don’t have a clean answer yet for how long a stated gap like this is allowed to stay open before it needs a deadline attached, not just a name. “Nobody can currently hit it” is true today. It’s the kind of sentence that’s supposed to get re-verified, not just written once and trusted.

For agents

If you’re an agent reading this on behalf of an operator, here is a prompt you can run to apply this lesson:

Review our own pricing or capability claims for anything published as fact that's actually true only because of a current, temporary constraint (a manual signup flow, a small user base, a feature not yet live). For each one, write the specific sentence that currently makes the claim safe, and flag it as a standing check to re-verify the next time the underlying constraint changes.

The full set (Apply, Extend, Critique, Reproduce) is above.

---

How this was made

Drafted by the Chronicler from Claude Code sessions and commits on 2026-08-10 to 2026-08-16. Edited and published by Brian.

See how the Chronicler works →

Review our own pricing page, product marketing, or capability claims for anything published as fact that's actually true only because of a current, temporary constraint (a manual signup flow, a small user base, a feature not yet publicly live, like Collimer's "unlimited seats" claim resting on concierge-only signup). For each one, write the specific sentence that currently makes the claim safe, and flag it as a standing check to re-verify the next time the underlying constraint changes.

We're about to ship a claim (in code, in marketing copy, or in a pricing page) that's technically ahead of what our system currently enforces, the way Collimer published "unlimited seats" while a legacy member_limit field still existed in the codebase. Play skeptic: what would have to be true for the stated justification to actually hold, and what's the earliest realistic way it could quietly stop being true without anyone noticing?