Stop paying for design system documentation you can build yourself

TL;DR

Paid DS documentation platforms cost $2k–$10k/yr, can’t handle multi-platform systems, and are invisible to AI agents.

This article is a practical guide to replacing them with free, open-source tools — where AI writes the docs from your Figma and code repos, designers edit through a visual interface, and the site auto-deploys.

Two weeks to set up. Real trade-offs included.

For a while, tools like Zeroheight and Supernova genuinely made our lives easier. If you didn’t want Figma to double as your documentation, didn’t want to rely on Markdown files, and didn’t want to push your designers into engineering-oriented tools like Storybook — these were the answer. You paste your Figma library link, pick which components you want to display, and you’ve got a decent-looking documentation site without writing a single line of code.

That was a big deal. But it doesn’t make sense anymore.

With the rise of MCP servers, AI agents, and solid open-source documentation tools, you can build something that’s more powerful, more flexible, and way cheaper. And I’m not talking about a hypothetical future — I’m talking about tools you can set up this week.

What changed

It’s become so easy to fetch data from Figma — using the Figma REST API, Figma MCP, or the Figma Console MCP — that the main value proposition of tools like Zeroheight has evaporated. The “we pull your Figma components so you don’t have to” pitch made sense when doing that yourself was hard. It’s not hard anymore.

At the same time, LLMs have gotten good enough to act as technical writers. You can point an AI agent at your Figma library and your code repos, and it’ll generate accurate documentation pages — with real token values, real component APIs, real specs. Not hallucinated approximations. Actual data, extracted from the source.

So now you’re paying for a platform that does less than what you can do yourself with free tools.

What these platforms actually cost you

Let’s put numbers on it.

Zeroheight’s Starter plan is $49/editor/month. A team of 5 editors runs you ~$2,940/year. And Starter is limited — you get 2 styleguides, 3 token sets, no API access, no SSO, no adoption tracking. For the features most design system teams actually need, you’re looking at their Enterprise plan, which requires a sales call. Third-party estimates put the Pro tier at around $800/month, so roughly $9,600/year.

Supernova’s Pro plan charges $35/month per “Full seat” (yearly billing). Five seats is $2,100/year. Enterprise is custom pricing.

These aren’t outrageous numbers for large companies. But they’re not trivial, and they come with limitations that cost you more than money.

Where these tools are actually hurting you

The cost isn’t the real problem. The real problem is that these platforms were built for a world that doesn’t exist anymore — a world where one design system maps to one tech stack.

The multi-platform mess

Most of these tools assume 1 Figma component = 1 React component. That’s their mental model, and everything is optimised for it.

But if you’re like most growing teams, you actually have 1 Figma component = 1 React component + 1 SwiftUI component + 1 Jetpack Compose component. And suddenly you’re stuck finding sketchy workarounds:

• Manually managing component status per platform (which is a maintenance nightmare)
• Embedding .md files or using iframe blocks to show platform-specific code
• Self-hosting separate web pages just to document your iOS and Android APIs

What usually happens? You give up. The documentation becomes designer-oriented, engineers rarely look at it, and everyone goes back to inline docs in each code repo. The whole point of a centralised documentation site is defeated.

The AI-readiness gap

This is the one that’s going to bite people hardest over the next year or two.

Your design system documentation is increasingly the instruction manual for AI agents. When product teams use Claude, Cursor, Bolt.new, or Lovable to generate UI, the quality of the output depends entirely on how much context the AI has about your design system — tokens, component APIs, usage rules, accessibility requirements, content guidelines.

If your documentation platform can’t expose that information in a structured, machine-readable way, it’s failing at what’s quickly becoming its most important job.

Here’s a concrete example: Zeroheight has a native block that displays text styles from your Figma library. Humans can see the styles on the page. But Zeroheight’s API can’t actually extract the data from those blocks. The information is visually there but programmatically invisible. An AI agent reading your docs through the API would have no idea those styles exist.

Side-by-side: a Zeroheight page showing text styles as a human sees it, versus what an API call returns (missing data)

Quick aside: why documentation matters even more now

You might be thinking: “If AI can read my Figma and code directly, do I even need documentation?”

Yes. Here’s why.

When your design system is small — just Figma and a React codebase — the source of truth is obvious. But when you start expanding to multiple tech stacks and platforms, you end up with multiple sources of truth. People start asking “where’s the reliable place where I can learn everything about this component?” — its status on each platform, its API for each tech stack, usage guidelines, accessibility notes, content design rules.

Documentation becomes the aggregator. The one place that ties everything together.

And for AI agents, that aggregator role is critical. The documentation is what you feed into Claude or Cursor so that generated UI is consistent with your product and brand. It’s the context layer that makes AI-assisted development actually work at scale.

What you can build instead

Every tool here is either open-source or has a free tier that covers what you need.

The engine: Docusaurus

Open-source, built by Meta, designed specifically for documentation. It supports MDX — which means you can drop live React components directly into documentation pages. Built-in search (via Algolia DocSearch, free for open-source projects), versioning, dark mode.

The killer feature for design systems: Docusaurus has a native Tabs component. One component page, multiple tabs:

• Design tab: Visual specs pulled from Figma

Code:

• Web tab: Live Storybook embed or React code snippets
• iOS tab: SwiftUI snippets pulled from your repo
• Android tab: Jetpack Compose snippets pulled from your repo

That multi-platform problem? Solved, for free.

Documentation rendered with Docusaurus

The designer-friendly layer: TinaCMS

Open-source, self-hostable. Cloud plans start at $29/month for teams if you want the hosted version. Otherwise, it’s free.

This is what makes the whole thing work for non-technical team members. TinaCMS gives your designers a visual editing interface at yourdocssite.com/admin. They see a WYSIWYG editor — fields for “Description,” “Do’s and Don’ts,” image uploads. When they hit Save, TinaCMS writes the content into a Markdown file and commits it to your GitHub repo. The designer never sees Git. They never see Markdown. They just edit and save.

You define a schema (basically a template) that structures each page type, so the experience is guided and consistent — not a blank text editor.

Screenshot from https://demo.tina.io/

The glue: Figma Console MCP + code repo MCPs

This is where AI enters the workflow. The Figma Console MCP bridges your Figma library and your documentation files. Instead of a designer manually typing “Button corner radius: 8px,” an AI agent queries Figma directly and extracts the actual value.

Combine that with a GitHub MCP, and the same agent can also read your component source files — Swift, Kotlin, React — to pull API details, props, and default values.

The AI becomes your technical writer. You prompt it: “Scan the Primary Button in Figma and the Button.kt file in the Android repo. Generate an MDX page listing design tokens vs. code properties for each platform.” Out comes a .mdx file, ready to commit.

Hosting: GitHub + GitHub Actions

Free. Your docs repo lives on GitHub. Anytime someone pushes a change — whether it’s a developer merging code, a designer saving through TinaCMS, or an AI agent updating specs — GitHub Actions triggers a Docusaurus build and deploys to GitHub Pages. You can also use Vercel or Netlify, both free for this use case.

How this works in practice

A designer changes something in Figma

1. Designer updates the “Primary Button” corner radius in Figma.
2. They run a command (or a scheduled job does it automatically): “Update the Button documentation.” The AI agent grabs the new values from Figma via MCP and updates button.mdx.
3. The designer opens the TinaCMS admin, sees the updated specs, and adds a note: “Use this button for main calls to action.”
4. The site redeploys. Done.

An engineer changes a component API

1. An Android engineer corrects a property value in the Button component.
2. After the PR merges, a GitHub Action triggers the AI agent to update the Android section of button.mdx.
3. The site redeploys. The Android code snippets are current.

No manual documentation updates. No “hey can someone update the docs?” Slack messages that get ignored for three (or more?) weeks.

How to actually get started

You don’t need to build everything at once.

Week 1: Setup the website.

• Stand up the site. Scaffold a Docusaurus site (npx create-docusaurus@latest my-ds-docs classic), push it to GitHub, set up GitHub Pages deployment. You now have a live, free, version-controlled documentation site.
• Add the designer-friendly editing layer. Integrate TinaCMS. Define schemas for your page types. Your designers can now contribute from a browser.
• Connect your sources of truth. Set up the Figma Console MCP. Write a prompt template for your AI agent to generate.mdx pages from Figma data and code repo data.

Week 2: Automate. Create a GitHub Action on a nightly schedule (or on PR merge) that triggers the AI agent to check for changes and update docs. Add a Slack notification so the team knows when something’s been auto-updated.

Two weeks from zero to a fully automated, multi-platform, AI-ready documentation site. No subscriptions (!)

Being honest about the trade-offs

You’re trading subscription costs for engineering time. That means:

• You (probably) need a developer for the initial setup. A designer can’t scaffold this alone. Someone needs to be comfortable with Node.js, GitHub Actions, and basic MCP configuration. (Perhaps Claude or Cursor can help you with this part.)
• You own the maintenance. When Docusaurus ships a breaking update, that’s your problem, not Zeroheight’s.
• MCP tooling is still maturing. Expect some rough edges. These tools are being actively developed and things move fast.
• You lose some out-of-the-box conveniences. Zeroheight has adoption dashboards. Supernova has built-in Storybook playgrounds. You can replicate these (Docusaurus + Plausible Analytics for tracking, Storybook iframe embeds for playgrounds), but it’s more work.

For a solo designer maintaining a small system, Zeroheight’s free tier might still be the pragmatic choice. But for any team that’s scaling, supporting multiple platforms, or trying to make their design system AI-ready, the math changes fast.

Where this is all going

We’re at a point where connecting all your design system’s sources of truth is so easy that building a custom solution tailored to your actual needs makes more sense than conforming to what expensive, generic platforms offer.

Your documentation isn’t just a reference site anymore. It’s the context layer that powers every AI-assisted design and engineering decision your team makes. Build it like it matters.

Tools and resources:

• Docusaurus — Installation · Tabs · Deployment
• TinaCMS — Docusaurus Integration · Pricing
• Figma Console MCP
• GitHub MCP Server
• Figma REST API
• Zeroheight Pricing · Supernova Pricing
• MDX · Storybook
• GitHub Actions · GitHub Pages
• Algolia DocSearch · Plausible Analytics
• Vercel · Netlify