Why we built our own changelog platform

Konde publishes a lot of content surfaces. We have a docs site for Konde Studio. A changelog for every product. A blog for the company. And as we onboard partners, we want each partner to get the same set of surfaces under their own subdomain — docs.partner.io, blog.partner.io — themed to their brand.

For the first three months we tried doing this with off-the-shelf tools. Mintlify, ReadMe, GitBook. All of them are good products. None of them fit. Here is why, and what we built instead.

#What we tried

Mintlify is the slickest of the three. Beautiful out-of-the-box, fast, well-priced for a single doc site. The problem for us: every site is a separate Mintlify project with separate billing, and their multi-tenant story (one parent account, many child sites) is not really designed for an org running thirty subdomains. We would have been managing thirty Mintlify projects manually within a year.

ReadMe is more enterprise-flavoured. Good API documentation features, decent versioning. The pricing scales aggressively with team size, and the editor experience felt heavier than we wanted for a daily-publish blog.

GitBook is the polar opposite — focused on team-wiki workflows, wonderful for internal docs, awkward for public-facing developer documentation. The "publish to public" flow felt bolted-on.

All three would have worked for one site each. None of them would have scaled to "thirty themed sites under thirty subdomains, each running docs + changelog + blog from the same primitive."

#What we actually needed

Stripped to essentials, our requirements were:

1. One codebase, many tenants. Adding a new tenant should be a config change, not a new project setup. Each tenant gets its own subdomain, theme, and content store.
2. Three content types from one engine. Docs (hierarchical, with a sidebar nav), changelog (chronological, version-stamped), blog (chronological, with categories). Not three separate products glued together.
3. Markdown in, fast HTML out. Authors write .md files. The platform handles everything from there. No proprietary editor, no JSON config, no MDX runtime.
4. Edge-fast. Sub-50ms render globally. Konde users live in Indonesia and Vietnam; we cannot afford 800ms first paint.
5. Cheap. Tens of small sites at $5/month each, not one big site at $300/month.
6. Theme-aware. When the brand picks seafoam, every kdoc site repaints. Same theme system as Studio (KDF).

No vendor met more than two of these.

#What we built

kdoc is a single Cloudflare Worker codebase, deployed once per tenant. Total bundle size: 200KB. KV-backed content store. Three content types (docs/changelog/blog) handled by a unified routing engine with per-type templates. Themed via KDF. Author registry deduped via a _author:{slug} lookup.

We have written the architecture in detail in Why we built kdoc on Cloudflare Workers. The summary: it is a small Hono app, a flat KV schema, and per-template stylesheets that compose into one document-level CSS variable cascade.

The deploy flow is npx wrangler deploy --env <tenant-name>. Each env in wrangler.toml is a tenant — its own KV namespace, its own custom domain, its own theme defaults. Adding a new tenant is fifteen lines of config and one DNS record.

#What we deliberately do not do

• No WYSIWYG editor. Authors write Markdown. We considered a panel for non-technical authors and decided against it — every Markdown editor we have ever shipped has needed three rounds of UX rework before it stopped getting in the way. Markdown is the editor.
• No comment system. Disqus is malware-adjacent. Hosting our own comment server is operational overhead. If you want comments, link to a thread on X or a Discord channel.
• No analytics out of the box. Plug in Plausible, Tinybird, or your own pipeline. We are not in the analytics business.
• No A/B testing. Same reason.
• No edge-side includes or partial revalidation. The content rarely changes; aggressive Cache-Control plus a manual purge on publish covers our needs.

These are deliberate scope cuts. Each one would have added complexity to the codebase, and each one was solved better by an existing tool you can plug in if you need it.

#Should you build your own?

If you have one or two doc sites, no. Use Mintlify or ReadMe. The tooling is mature and the time saved is real.

If you have thirty doc sites that all need to share themes, deploy quickly, and run on tight infrastructure, yes — building something like kdoc on Workers + KV is genuinely cheaper, both in dollars and in operational complexity. But you have to be honest about whether you are at that scale. Most teams are not, and the temptation to build your own because the existing options have rough edges is how scope balloons into a side-quest.

We open-sourced kdoc at konde/kdoc. If you want to fork it for your own publishing setup, the core is genuinely small — under 5,000 lines including the templates. We will not be running it as a hosted service for third parties; that is exactly the trap we want to avoid.

If you build something useful on top of it, post it on X with #kdoc. We will boost it.