Why we price gated docs by reader, not by space

Spaces were the obvious metric, and the wrong one

A space in DocuGate is one published docs site, read from a repository. The first paid plan, Pro, was sold on two things the server actually enforces: private repositories, and more than one space. "Unlimited spaces" is still on the Pro card.

In a pricing review on 2026-09-18 we asked which number grows with what a customer gets from DocuGate, and spaces failed the test. A hobbyist has five side projects. A company has two docs repositories. The person with more spaces is often the one with less money and less need, so a price that climbs with spaces charges the wrong people and undercharges the right ones.

Readers track it

The number that does grow with value is gated readers: people who have to sign in before they can read. By our estimate in that review, a solo developer gating docs has one to three readers, and a company gating its internal engineering docs has forty. The reason somebody puts a gate in front of documentation is that specific people should read it, so the count of those people is close to the thing they are paying for.

It is also knowable. An allowlist space stores its list, so its reader count is the list's length. A repository-access space delegates to GitHub, so its count would be the repository's collaborators, which takes one more GitHub call per space; we do not fetch it today. A public space has no gated readers at all.

Fence on who reads, not on whether it is gated

The consequence is the line in our pricing notes we hold to most: paid tiers fence on who reads, not on that it is gated at all.

That matters because a gate is not scarce. When we checked on 2026-09-18, Mintlify's pricing page put authentication on its free tier, and Docusaurus on GitHub Pages costs nothing and has no gate at any price. If our paid plan meant "you may have a gate", we would be charging for something a competitor gives away. If it means "you may have more people behind the gate", the fence is the size of the team that needs it, and every plan, including the free one, gets the gate.

The design, and what is not built

Plan	Price	Gated readers
Starter	$0	3
Pro	$5/mo, $50/yr, or $2/wk	10
Enterprise	from $29/mo	Unlimited
Custom	Quoted	Unlimited

The reader caps are the design. They are not enforced. On the pricing page the row carries a building tag, which is how every row that is a plan rather than a fact is marked. The changelog's Coming next lists reader counts as being built, and nothing is charged on them.

We wrote the build order down because doing it out of order breaks the idea: count readers, then the custom domain, then the limit, then Enterprise. Counting comes first so there is a real distribution to set the limit against, rather than numbers chosen in a meeting. A limit without a custom domain beside it leaves Enterprise fenced only by priority support, which is a nicety that gets negotiated away. A fence has to be something a buyer needs.

Two rules come with it. Grandfather everyone: every account that exists the day a limit ships keeps unlimited readers, permanently. And watch the counter-metric: distinct sessions per allowlisted email. If it climbs after the limit ships, readers are sharing logins, and the fence is in the wrong place.

The decisions we reversed

Pricing documents usually show the final answer. Ours has a decision log, and the reversals are the more useful part.

A $250 Enterprise card, dropped the same afternoon. On 2026-09-18 we drafted a top tier at $250 a month fenced on SSO, an SLA and data residency. None of those exist. Seven days earlier we had deleted the whole Enterprise page for the same fault: a feature matrix that was really a roadmap. So the card went, and the compliance asks became something we quote rather than list.

We wrote down what that costs. A high price nobody buys still does work on a price list, because it makes the middle look reasonable. Without it, the largest number on our page is $29, and that caps what people imagine paying. We kept the decision anyway, because a number we cannot honour is worse than a low one.

Team became Enterprise. The $29 floor launched on 2026-09-18 as a Team plan. On 2026-09-22 it was renamed Enterprise and given a narrower job: a custom domain, and API keys for the customer's developers. Those are what make leaving costly: once docs live at docs.theirco.com and developers hold keys issued there, moving means a dead link in every README and a rotated key in every integration. SSO, SLAs and data residency moved to Custom. Enterprise and Custom both open an email rather than a checkout, because a working pay button would be selling things that did not exist when the cards were drawn.

Four cards became two, with no price changed. $0, $2, $5 and $50 side by side read as four plans when three of them are Pro on different cadences. It also left readers to work out that $2 a week, the smallest number on the page, is the most expensive way to buy Pro: $8.67 a month against $5. Pro is now one card with the cadences inside it, each showing what it comes to per month. A cadence toggle had been tried before and dropped, because it hid two of the three prices behind a click.

Early access was removed, not expired. A date in an environment variable that gave Pro away was replaced with discount codes, which are bounded and auditable.

Why $5 stays where it is

As we read their pricing on 2026-09-18, GitBook charged $249 a site per month plus $12 a user before it would gate a page, and ReadMe about $99 a project. Our notes mark those figures to be checked again before anyone quotes them, and they will change. The gap is still the argument for keeping Pro at $5 and building a tier above it, rather than raising Pro.

There is a cost reason too. Vercel's free Hobby plan is non-commercial, so the first paying customer moves our hosting to Vercel Pro at $20 a month. After Polar's cut, $5 nets about $4.40: six Pro subscribers just to cover hosting, or one Enterprise subscriber alone.

The trade-off

Reader-based pricing asks us to count people, and counting people invites sharing logins. A three-person team on Starter has a reason to use one account. The counter-metric is how we would see it, but seeing it is not fixing it.

It also makes our cheapest plan less generous on paper than "unlimited readers, pay per site", which is easier to explain. We decided the fence should be where the value is, even when it is harder to say in one line.

What we would do differently

Count readers before drawing the table. Today the caps of 3 and 10 are on the page before we have any distribution of real reader counts to set them against, and the building tag is doing a lot of work. If we started again we would ship the meter first, quietly, and put numbers on the page only once the data had chosen them.