Knowledge Base App Starter · Industry version
Developer Documentation Template
A docs site that understands releases, code samples, and error-message searches — generated into your own repository.
Developers don't read docs; they search an error string at 2 a.m. and judge you by what comes back. This starter generates a documentation site built for that reality — docs versioned per release, samples that stay tabbed by language, search that matches API names — and hands you the code, so your docs pipeline can live next to your product's.
- 6 core entities
- Full-text search
- Code you own
- Vibe + Governed modes
01 · The problem
Why a generic Knowledge Base falls short
Generic knowledge bases version pages; developer docs need to version the whole tree. When v3 renames half the API, a reader on v2 needs the v2 sidebar, the v2 samples, and the v2 truth — not a page with a 'this changed recently' admonition bolted on. Without release-pinned doc versions, every major release turns your docs into a minefield of half-true pages.
Code samples rot differently than prose. A wrong sentence misleads; a wrong snippet gets pasted into production and pages someone. Samples stored as untyped rich-text blobs inside articles can't be extracted, linted, or compiled in CI — so nothing tells you the quickstart broke until a furious signup does.
And developer search is its own discipline. Queries are exact strings — ERR_CONNECTION_RESET, createClient, a header name — that natural-language relevance mangles. If exact identifier matches don't outrank prose mentions, the search box teaches developers to use an external search engine instead, and you lose the analytics that tell you what's missing.
02 · Data model
The data model, adapted
Everything in the base Knowledge Base starter —
spacesarticlesarticle_versionscategoriesfeedbacksearch_queries— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
doc_versions | Named doc trees pinned to product releases — v2, v3, next — each with its own navigation, samples, and search index. |
code_samples | Snippets as first-class rows with language, target release, and source path — extractable into CI so the quickstart compiles before it publishes. |
03 · Screens
Modules through the industry lens
Release-pinned doc tree
01A version picker swaps the entire tree — sidebar, pages, samples — to the selected release, with canonical tags pointing search engines at the current one. Readers on old versions see banners, not broken instructions.
Samples that build in CI
02Because snippets are structured rows with a language and source path, a CI job can extract and compile every sample against the release it documents. A failing sample blocks the docs publish the way a failing test blocks a deploy.
Identifier-first search
03Search ranks exact matches on function names, error codes, and config keys above prose hits, and logs every zero-result query. That log — the error strings your users hit that your docs don't cover — becomes the docs backlog, sorted by frequency.
04 · In practice
Workflows it models
Cutting docs for a release
01Branch the current doc version into the next, update the pages that changed, and let CI compile the samples against the release candidate. On launch day, publishing the new version flips the default tree in the same motion as the product ships.
Deprecating an endpoint
02Mark the endpoint's pages deprecated in the current version and gone in the next. Old-version readers keep accurate docs; current-version readers see the migration path; search stops recommending the endpoint to anyone new.
Triaging zero-result searches
03Weekly, sort the search log by zero-result frequency. The top entries are usually an undocumented error message and a misspelled method name — one becomes a new page, the other becomes a search synonym, both are ten-minute fixes with measurable payoff.
Developer Docs template — frequently asked questions
Can it version docs per product release?
Yes — doc_versions pins an entire tree to a release, so v2 readers get the v2 sidebar, pages, and samples. A picker switches versions, and canonicals keep search engines on the current release.
How do code samples stay correct?
Samples are structured rows, not blobs in rich text — each carries a language and target release, so a CI job can extract and compile them before publish. Broken samples fail the docs build instead of failing your users.
Can docs live in the same repo as the product?
The generated app is a standard codebase, so it can sit in your monorepo, share CI, and even pull reference content from source at build time. That's the payoff of owning the docs app rather than renting a docs platform.
Does it support an API reference section?
The starter gives you the tree, versioning, and search; a generated API reference is a natural extension — a build step that renders your spec into articles rows. Because the schema is yours, reference pages get the same search, feedback, and versioning as prose.
Related
Dual7 App Starters
Build your Developer Docs on your terms
A docs site that understands releases, code samples, and error-message searches — generated into your own repository. Describe your version to start — the output is a project you own.