A design system documentation site
in one HTML page, with the real components

The tokens live in a JSON file, the components live in a stylesheet, and the documentation lives nowhere. New people get a Figma link and a Slack message that says "use the primary button". Somebody suggests Storybook, somebody else prices zeroheight, and the design system goes another quarter without a page that shows what a button looks like when it is disabled.

This guide is about publishing design system documentation as one page, with the components rendered for real, free. Hostus is the option we put first, and the category matters: best if the design system is already HTML and CSS, because the documentation shows the real component, not a screenshot of it. Storybook, zeroheight, Supernova, Figma and a Notion page each have a case, covered below with what their own sites said today.

What the team sees

Here is one, live: the design system of a fictional product, on one page. Principles at the top, then colour and type tokens as swatches and a scale, spacing, buttons in every state, fields, cards, a table, and a toggle in the header that switches the whole page to the dark theme. The product does not exist and the token values are illustrative; the components are real CSS, rendered by the browser you are reading in.

Flip the toggle and every swatch changes, because it flips the same custom properties the components use. That is the difference between showing the component and showing a picture of it: a screenshot is right on the day it was taken. Each section is a heading with an id, so "the fields section" is a link, and a reply written on it stays there.

How it works on Hostus

Hostus hosts a single HTML file, with its fonts and images, as a page at yourslug.hostus.page. Drop the file in, or let Claude publish it through the connector. The JavaScript keeps running, so a theme toggle works on the link the way it did on your laptop. No build, no framework, nothing to install for the people who read it.

What happens once the team has the link:

• The reply lands on the section. Reply is on by default. A developer who thinks the spacing scale skips a step says so on the spacing section, with no account. The conversation is private between that reader and you, you get an email, and you answer from the dashboard or through Claude.
• You see which sections are read. Reading by section shows which sections each reader opened and for how long. If everyone opens buttons and nobody opens the table, you know.
• The next version goes up on the same link. Change a token, upload the file again, and the link the team bookmarked shows the new version. The previous ones stay in a history, which is the changelog you were not going to write.
• Internal stays internal. Pages are served with a noindex meta and never appear in Google. For a system that should not leave the company, switch the page to email-gated: a reader types an email before it opens, no account, and you see who did.
• The page answers questions. Ask is on by default. "What is the minimum tap target?" gets an answer from what the page says, with the section cited. The questions the page could not answer are listed for you, and they are the sections you have not written yet.

The prompt

Paste in the tokens file, or the stylesheet, or both. If you have neither, describe the brand in two lines and Claude proposes the tokens. Hostus connector on.

Here are my design tokens (JSON below) and the component stylesheet (CSS below). Write a one-page design system documentation site from them.

Sections, each a heading with an id: principles (three short ones), colour tokens as swatches with the name, the value and the use, type scale with each size rendered in itself, spacing scale as bars, buttons (primary, secondary, ghost, each in default, hover, focus and disabled), fields (text, select, textarea, with error and help text), cards, and a data table. A sticky nav that jumps to each section. A dark theme toggle in the header that flips the custom properties, and every component must follow it. Use the real CSS, not screenshots, and keep every variable name as it is in my file.

No backend, no localStorage, no key in the page, one HTML file, mobile first.

Publish it to Hostus and give me the link.

Claude publishes the page with hostus_upload. The page is born private: switch it to email-gated (or public) in the Hostus dashboard before you share the link with the team. Ask and Reply are already on. When a token changes, paste the new file and say "update the same page": the link does not change.

What goes on a one-page design system doc

The page is short because it is one page, and that is the point. The order the prompt above follows:

• Principles. Three lines, not a manifesto. They are the tiebreaker when the tokens do not settle an argument.
• Tokens. Colour as swatches with name, value and use (--color-danger, the hex, "destructive actions and errors"). Type as a scale where each size is rendered in itself. Spacing as bars in proportion. A token nobody can see is a token nobody uses.
• Components, with their states. The default state is the one everybody gets right. Disabled, focus, error and loading are where systems drift, so each component shows them side by side.
• Do and do not. One rendered pair per component at most: the right button next to the wrong one.
• Which version this is. A line at the top with the version and the date; the history on the link holds the rest.

The component source stays in the repo; link it from the header. The page documents; the repo ships.

Storybook, zeroheight, Supernova, Figma, a Notion page: pick it if

Hostus first, for the case this page is about: the system is HTML and CSS, you want it documented on one link with the components rendered, and the team should reply without an account. The rest were read on their own sites on 18 October 2026; where a site did not say, this guide says "check their pricing page" rather than a number.

• Storybook. Pick it if the components are React, Vue or another framework and the developers will keep the docs next to the code. Its site says "It's open source and free" and describes it as "a frontend workshop for building UI components and pages in isolation", used "for UI development, testing, and documentation". It is installed into a project with npm create storybook@latest and runs where the project runs, so somebody has to host it. For plain CSS, that is a lot of machinery around one page.
• zeroheight. Pick it if designers own the documentation and want Figma styles pulled in. Its pricing page lists a Free plan at $0 with 1 editor, 1 styleguide and 1 token set, and Starter at $49 per editor a month after a 14-day trial (its FAQ gives $59 if paying monthly or $588 a year). Custom domain, a shared password and commenting are on Starter; page history is kept 7 days on Free and 30 days on Starter.
• Supernova. Pick it if you want tokens, Figma and Storybook pulled into one platform with code exporters. Its pricing page lists Starter as free with 3 editors, 1 design system, 20 documentation pages, 3 Figma data sources and 1 Storybook data source, on a public documentation site; Pro is $399 a month and adds a private site, a custom domain and custom code exporters. Enterprise is "Contact us".
• Figma. Pick it if the system lives in Figma and the people who read the docs already have Figma accounts. Starter is free. Two limits matter for documentation: prototype-only links are a paid feature, and to comment a reader has to be signed in. A Professional full seat is listed at $16 per month. The Figma component is a drawing; the one in the browser may have drifted.
• A Notion page. Pick it if the documentation is mostly prose and a screenshot per component is acceptable. Notion's Free plan is $0 with basic page analytics (a list of page viewers); Plus is $10 per seat a month. A Notion page cannot run your CSS, so the toggle is a picture of a toggle.
• A README in the repo. The baseline. Free, versioned, next to the code. Designers do not open it, nothing is rendered, and nobody outside the repo knows it exists.

Side by side

Prices and limits were read on each vendor's own site on 18 October 2026 and change without notice. The first column decides most of it: if the docs must show the component as the browser renders it, the file that holds the CSS is the documentation.

Keeping the documentation alive

Design system documentation dies of staleness, not of absence. Two things work against that. The link: v2 replaces v1 on the same address, so there is never an "old docs" URL pinned in a channel. The signal: reading by section tells you which parts are read, the unanswered questions from Ask which parts are missing, and the replies which parts are wrong. Ask Claude once a month what the page needs and it goes through all three before proposing an edit; it proposes, you decide.

For a team, put the pages in a shared folder: tokens on one, components on another, patterns on a third. Readers see every page; contributors add their own without touching yours. A new hire gets one folder link. The folder has no menu of its own, so each page should link to the others in its header.

Good to know before you switch

One document is one page. A folder groups pages and a shared folder gives the team one link to all of them, but there is no site navigation, no sidebar and no search across pages; a system that needs forty pages in a tree is a multi-page site, which is what zeroheight and Supernova sell. The page documents the system; it does not ship it. There is no npm package, no token export and no code generator: the tokens the page shows are the ones you pasted in, and the repo stays the source of truth.

The free plan is 2 MB of storage in total, with fonts and images counting, and 20 documents, with no clock and no card; the paid plan is 200 MB. Font files count, so load them from where they already live. There is no custom domain on any plan: the address is always yourslug.hostus.page. The gate for an internal page is by email, not by password, and a page cannot be embedded in another site.