The state of docs platforms (and where Mari fits)

Daniel Henneberger · 2026-05-07

I'll save you the throat-clearing: most "docs platforms" are publishing tools. They take your already-written prose and put a search bar on it. That's useful — and it's also not the bottleneck on any team I've ever shipped with.

The bottleneck is the writing.

Below is the honest landscape, as of mid-2026.

The incumbents, in one sentence each

Mintlify — beautiful API docs, MDX-powered, AI search bolted on. Fast to set up. Doesn't write anything for you.
Fern — best-in-class API reference generation from OpenAPI specs, with SDKs as a bonus. Excellent at the API surface; silent on everything else.
ReadMe — the originator of "API hub." Strong analytics, weak on auto-generation, expensive at scale.
GitBook / Notion — wikis with publishing. Search and SSO are fine. The content rot problem is yours.
Mari — AI content management for coding agents. Mari drafts docs from your code, checks your facts against the source, and opens pull requests. Every fact gets an owner and a sign-off, and drift gets caught after it ships.

If your problem is "we have great docs but the website is ugly," go pay Mintlify.

If your problem is "we have an OpenAPI spec but no SDKs," Fern earns its money.

If your problem is "we don't have the docs, and writing them is the work no engineer wants — that's where the rest of this post is for.

The feature picture

I'm cautious about feature tables — they invite cherry-picking. So here's the table with the cherry-picking out in the open: this is the work I think matters for a docs system, not a publishing pipeline. Reasonable people will disagree on the rows.

Capability	Mintlify	Fern	ReadMe	Mari
Polished published site	✅	✅	✅	✅
Search (LLM-powered)	✅	✅	✅	✅
Versioning	✅	✅	✅	✅
API reference from OpenAPI	✅	✅	✅	✅
SDK generation	⚠️	✅	⚠️	❌
Drafts prose from your code + PRs	❌	❌	❌	✅
Checks facts against the source	❌	❌	❌	✅
Detects stale docs against shipped code	⚠️	⚠️	❌	✅
Opens PRs to fix what it finds	❌	❌	❌	✅
An owner and a sign-off on every fact	❌	❌	❌	✅
Style-tuned to your house voice	❌	❌	❌	✅
Self-hosted runners (data stays in VPC)	❌	⚠️	❌	✅
Audit log + SSO + SAML	✅	✅	✅	✅
SOC 2 Type II	✅	✅	✅	✅

Legend: ✅ shipped, ⚠️ partial / on roadmap, ❌ not really.

The interesting rows are the bold ones. Every other vendor on this list assumes a human will write the words. Mari is the only one whose roadmap is organized around not assuming that.

Why we don't try to compete on the publishing layer

Two reasons.

One, the publishing layer is commoditizing fast. Mintlify is good. Docusaurus is free. Once you have content, getting it on the internet looking nice is a solved problem.

Two, every minute spent making the published site shinier is a minute not spent on the actual problem: the docs aren't written. Or they were written eighteen months ago and the system has drifted past them.

So Mari embraces this:

We render to your existing platform. Use Mintlify, GitBook, Docusaurus, plain MDX in a docs/ folder. Mari opens PRs against whatever you already host. We are upstream, not in the way.

If you're shopping for "the prettiest docs site," we'll cheerfully point you at Mintlify and tell you to come back when you want the docs themselves to be a less-painful problem.

What's not in the table

A few things I deliberately left off because they don't decide the purchase, even though vendors like to lead with them:

AI search is now table-stakes. Every vendor on this list has it. The difference between vendors here is statistical noise.
Per-language SDK quality matters if you live and die by your public API; if you don't, it's a footnote.
Editor experience — Mintlify and Fern both have decent in-browser editors. We don't, because we believe the editor is your editor and the source of truth is your repo.

Where we'd genuinely lose

To keep my honesty card valid:

If you have one engineer, no Slack history, and need a docs site today, use Mintlify. Mari needs context to be useful, and you don't have any to give it yet.
If you ship a public REST API to thousands of customers and your SDK is your product, Fern is sharper than us on that specific axis right now.
If your problem is "our docs are wrong because nobody trained us on the writing", that's a humans problem and software is the wrong tool.

What we want feedback on

Three questions we're actively weighing:

Sources: git and Slack are in. Which source does your team's truth actually live in?
Drift signals: which changes should page a doc owner, and which should just open a quiet PR?
The security review: what does a vendor reviewer need from us that /security doesn't already answer?

If you've already shopped this category and have opinions, open an issue. The harshest feedback is the most useful.

— Daniel