Docusaurus vs Supernova vs Zeroheight
We Evaluated Supernova and Zeroheight — We're Staying on Docusaurus
After a structured evaluation of third-party design system documentation platforms, we've decided to keep our current stack: Figma + Storybook + Style Dictionary + Docusaurus.
What We Evaluated
We looked at two SaaS alternatives that have been gaining traction in the design system space:
- Supernova — a documentation + token platform with a WYSIWYG editor and direct Figma sync
- Zeroheight — a similar SaaS offering aimed at bridging design and development documentation
Both promise to reduce the friction of authoring docs and keeping tokens in sync with Figma. Both replace Docusaurus as the documentation layer.
Why We're Staying
After a head-to-head comparison across 11 decision drivers, the result was close — 6–5. On raw numbers alone, the case for migrating was real. What broke the tie was AI integration.
The Decisive Factor: AI Integration
Our docs are MDX files on disk in a Git repo. Claude Code, Cursor, and any MCP-based agent can read, write, refactor, and generate pages natively — no glue code, no custom integration, no API wrappers. That's not a small thing.
With Supernova or Zeroheight, content lives behind a vendor API. There is no first-party MCP server for either platform (as of May 2025). To get the same agent access we have today, we'd need to build and maintain our own integration layer. The delta between "agent can touch your files" and "agent has to call an API you built yourself" is compounding every quarter as we invest more in AI-assisted workflows.
Some concrete things that work today and would break with a platform migration:
- Claude Code reads and writes MDX pages natively via the filesystem
- Cursor indexes the full docs repo for inline suggestions and refactors
- Any MCP filesystem or GitHub server works out of the box
- Bulk content changes are a script, not a support ticket
- Docs are grep-able, diff-able, and reviewable in PRs
"Docs as files in Git" is increasingly an asset. We're not giving that up.
Other Reasons We're Staying
Full ownership, zero lock-in
Our content is static HTML and Markdown in Git — version-controlled, diffable, grep-able, deployable anywhere. Both Supernova and Zeroheight store content in their cloud. Export paths exist, but you lose the authoring UX and all automations on the way out. The switching cost compounds over time.
Cost
Our current stack costs $0 in licensing. A 10-editor Pro plan on Supernova runs ~$2,880–$4,320/year. That's real budget for modest gain. The true cost of Docusaurus is engineering maintenance time (estimated at 2–5 dev-days/year), which we already absorb.
Versioning and i18n
Docusaurus ships first-class versioned docs and i18n support. Both evaluated platforms have weaker or plan-gated equivalents.
Custom UX and components
Our MDX pages use custom React components — recharts for token charts, interactive tables, image zoom. A block-based SaaS editor can't replicate this without a custom block API, which is bounded by the vendor's schema.
Search
We run Lunr today and can upgrade to Algolia DocSearch (free for open projects) with a drop-in config change. Neither Supernova nor Zeroheight's built-in search matches that.
Where the Alternatives Win
To be honest about the trade-offs:
- Authoring friction — designers can't edit MDX without filing a PR or asking engineering. Supernova's WYSIWYG editor solves this directly.
- Maintenance overhead — Docusaurus upgrades, React version drift, broken plugins, and lunr quirks are a real ongoing tax. With a SaaS, that burden shifts to the vendor.
- Documentation quality out-of-the-box — token tables, component specs, and asset pages come pre-built and Figma-synced on both platforms. With Docusaurus we build and maintain those ourselves.
- Figma → token → docs parity — both platforms sync Figma variables natively; our current pipeline (Figma → Style Dictionary → docs) has manual steps.
- Speed to publish — editing in a SaaS is minutes; our Git-based flow is hours.
These are real pain points. If docs were consistently falling out of date because designers can't make changes themselves, the calculation would be different.
What We're Doing Instead
Rather than migrate platforms, we're addressing the authoring friction within our current stack:
- Improving Style Dictionary automation to reduce token drift
- Documenting a lightweight contribution guide for non-engineers
- Exploring AI-assisted doc generation (Claude Code already reads and writes our MDX)
Decision Scorecard
| Driver | Winner |
|---|---|
| Cost | Current stack |
| Ownership & portability | Current stack |
| AI agent integration | Current stack |
| Versioning & i18n | Current stack |
| Search | Current stack |
| Custom UX & components | Current stack |
| Authoring ease | Supernova/Zeroheight |
| Maintenance overhead | Supernova/Zeroheight |
| Docs quality out-of-the-box | Supernova/Zeroheight |
| Figma/token parity | Supernova/Zeroheight |
| Speed to publish | Supernova/Zeroheight |
Final score: 6–5 in favour of the current stack. The margin is narrow — AI agent integration was the tiebreaker. Without it, the case for migrating was credible.
Revisiting This Decision
We'll revisit if any of the following changes:
- Token drift becomes a persistent, high-frequency complaint from design
- Supernova ships a first-party MCP server that makes it agent-friendly
- Budget allocation shifts and licensing cost is no longer a blocker