Small product guides on Anticode, and when to use a real docs tool
Anticode can host a small set of help articles well: a getting-started guide, a dozen how-tos and an FAQ, each on its own page, edited in the dashboard. It isn't a documentation platform. There's no site search, no versioned docs, no API reference generated from code and no docs-as-code workflow. If your docs need any of those, use a dedicated tool and keep Anticode for the marketing site.
Two very different jobs called "docs"
"Documentation" covers everything from five help articles for a booking app to thousands of pages of API reference across six product versions. Those are different problems. The first needs clear writing and a sensible list. The second needs search, navigation trees, versioning, code samples generated from source, and a review process that lives next to the code. Decide which you have before picking a tool.
| Question | Small guides (Anticode can work) | Real documentation (use a docs tool) |
|---|---|---|
| How many articles? | Up to a few dozen | Hundreds, growing |
| Who writes them? | Founder, support or a non-developer | Engineers, alongside the code |
| Do readers search? | They browse a short list | They search for a function or error |
| Multiple versions? | No | Yes, readers on old versions need old docs |
| Generated from code? | No | API reference from source or a spec |
How small guides work on Anticode
Keep the articles in a CMS collection, for example guides, with typed fields such as title, summary, category, body and a last-reviewed date. You edit entries in the dashboard. Anticode serves the collection as an index at /guides/ and each article at /guides/<slug>, so every guide has a stable address you can paste into a support reply.
Around the collection, build the rest as a normal multi-page site: an FAQ page for the short questions, a Contact page for everything the guides don't cover. The index works as your table of contents, so title the articles as tasks ("Connect your calendar", "Change your billing email") rather than features, and keep the list short enough to scan.
Writing help articles people finish
- One task per article. If the title has "and" in it, it's probably two articles.
- Start with the result. One sentence on what the reader will have done by the end.
- Numbered steps, each one action. Name buttons exactly as they appear in your product.
- Screenshots only where the next click isn't obvious. They go out of date faster than text.
- End with what to do if it didn't work: a likely cause and a way to contact you.
- Date it. A visible "last reviewed" date tells readers whether to trust it.
Where it stops working
- No search. Published Anticode pages run no scripts and there's no built-in site search. Past a few dozen articles, readers can't find things.
- No versioning. One collection holds one set of articles. Docs for v1 and v2 side by side would mean duplicate collections and manual upkeep.
- No docs from code. Nothing reads your source, OpenAPI spec or comments to produce reference pages.
- No docs-as-code. Articles are edited in the dashboard, not as Markdown files reviewed in pull requests.
- No nested sidebar navigation of the kind docs tools give you, with sections and sub-sections always visible.
- No code-block extras such as copy buttons or tabbed examples per language, since pages run no scripts.
- English only. No translated docs.
If several of those matter, Anticode is the wrong documentation website builder for you. Static docs generators such as Docusaurus (which supports versioned docs) and MkDocs (which includes a built-in search) are designed for exactly this, as are hosted documentation platforms.
A sensible split
A common setup is to build the product's marketing site on Anticode and run the docs on a dedicated tool at docs.yourproduct.com, linked from the navigation and footer. The marketing site gets Anticode's design systems, design checks and form handling; the docs get search and versioning. Keep the visual link between them simple: the same logo, the same action colour if the docs tool lets you set one.
If you're at the stage of five help articles and a waitlist, start on Anticode and move the docs out when they outgrow it. Collection entries are your own content and can be copied across. The changelog page and FAQ page cover two related pieces that do fit Anticode well.
Questions people ask
Can I add search to an Anticode docs site?
Not on the published site itself: design-engine pages run no scripts and there's no built-in search. Keep the guide list short and well titled, or use a docs tool.
Can AI assistants read my help articles?
Each published site serves an llms.txt describing the site for AI assistants, alongside its sitemap.xml and robots.txt.
Can I build an in-app help widget?
Not with a published Anticode site. Link from your product to the relevant guide's address instead.
Sources
- Docusaurus: Versioning, checked
- MkDocs: Configuration, search plugin, checked