Docs Platform, No Per-Seat Pricing
Documentation without per-seat pricing
The problem with seat-and-site metering
How DSR Docs prices differently
You don't trade away features for it
When this is the right fit — and when it isn't
Documentation without per-seat pricing If you run docs for a growing team or a widening product surface, you've probably felt the pricing bite another writer, a second product portal, or a bigger reader audience, and the renewal quietly reprices. DSR Docs removes that mechanic entirely. There is no per-seat, per-viewer, or per-site fee — it's a license you run as one self-hosted container inside your own environment, so your cost is a license plus the infrastructure you run it on, not a headcount you can't freeze. There's no seat counter, no per-site meter, and no usage limit to trip. The problem with seat-and-site metering The teams this matters to have usually been burned once already. You bought a hosted docs product, it worked, and then the renewal repriced — because you added a few writers, opened a second product's portal, or your reader audience grew. None of that made the docs meaningfully more expensive to serve, but the pricing model treats every editor, viewer, and site as a billable unit. The result is a cost you can't forecast and can't cap growth in your team or your product surface is the thing the bill is designed to track. The friction isn't only financial. Per-seat pricing quietly discourages the behavior you actually want. If every editor costs money, you stop giving occasional contributors accounts and route their edits through a bottleneck. If every site costs money, you cram unrelated products into one portal instead of splitting them cleanly. The pricing model ends up shaping your documentation architecture, and rarely for the better. How DSR Docs prices differently DSR Docs is a license you run on your own infrastructure — one container that runs entirely inside your environment, with no managed service to subscribe to and nothing that counts who is using it. Total cost is that license plus whatever the infrastructure you run it on costs — a fixed, predictable line rather than a variable per-seat subscription that reprices at renewal. Because the license isn't priced per seat, per viewer, or per published site, the things that inflate a SaaS bill simply don't inflate yours here. Adding an editor is creating a user with the editor role in the admin panel. Adding a viewer or a guest carries no billing consequence at all. Adding another documentation surface — a second product, a partner portal — means another domain or tab inside the same deployment, or another container, neither of which multiplies what you pay. You don't trade away features for it Avoiding a subscription doesn't mean settling for a thinner product. The same container renders OpenAPI 3.x, GraphQL (SDL or introspection), and Doxygen for C and C++ — including call and caller graphs — natively, alongside long-form Markdown guides. You get full-text search, an in-app browser editor so non-engineers can contribute without touching Git, and white-label branding (name, logo, favicon, colors, fonts) that hot-applies with no rebuild. For AI and offline workflows there's a "Copy for LLM" button, an catalog, a Markdown alternate link, and one-click print-to-PDF export. One modeling note a single domain attaches exactly one API schema kind. To cover multiple surfaces — say a REST API and a C SDK — you split them across domains or tabs. That's a structural choice, not a licensing gate; the extra domains cost nothing. When this is the right fit — and when it isn't This is the right fit when cost predictability is the point you're forecasting spend, you have many occasional editors or a large reader audience, or you've watched a per-seat-plus-per-site bill balloon and want cost that doesn't scale with headcount or site count. It also fits when self-hosting is already a requirement for other reasons, since the pricing model and the deployment model line up. It's the wrong fit if you'd rather not run any infrastructure. DSR Docs asks you to own the operational work a hosted service would otherwise handle — provisioning the host, terminating TLS at your proxy, and applying image upgrades. That's predictable work, but it is work. If nothing forces the docs onto your own infrastructure and you'd prefer a fully managed service, a hosted product removes operations that DSR Docs asks you to keep. A couple of related capabilities are also worth setting expectations on DSR Docs includes a built-in "Try It" console that fires live requests against a configured server for your OpenAPI operations, but it does not generate client SDKs and does not provide hosted API usage analytics. If SDK generation or hosted usage metrics are central to your portal, weigh that against what seat-independent cost buys you. [!IMPORTANT] Sounds like your case? Write to docs@dsr-corporation.com. We'll show you the engine on documentation like yours, and say plainly what a move would involve.