Fumadocs

The product

Fumadocs is a documentation framework for Next.js that fits into the App Router. It is split into three parts. Fumadocs Core handles search, content source adapters, and Markdown extensions. Fumadocs UI is the default theme. A CLI installs components much like shadcn/ui does. Fumadocs also offers adapters for Obsidian vaults and API reference pages generated from GraphQL schemas.

The developer problem

A docs framework serves two groups. Writers want to add a page in Markdown without touching a component. Engineers want search, navigation, and reference pages that stay correct as the product changes. A framework split into Core, UI, and a CLI gives a team parts to choose from, and each team then assembles its own stack. The hard part is the path from a new Next.js app to a working SDK docs site: which content source to use, how to set up search, and how generated reference pages stay in step with their schema.

My focus

• SDK docs-site builds. I’d start from a real SDK and build its docs site on the App Router end to end, running every setup step before writing it down, with versioned sections for SDK releases that are supported at the same time.
• Search integrations. I’d wire Fumadocs Core search into that site and test it against the queries developers actually type, so a renamed page or a moved section doesn’t drop out of the results.
• OpenAPI reference pages. I’d generate reference pages from the API spec in the same build as the written guides, so the reference changes when the spec does, not when someone remembers to update it.

Why it fits my experience

• At Meta I maintain versioned documentation across concurrent SDK versions, including deprecation notices and upgrade paths, and I build the sample projects before documenting them.
• At Meta I led a complete restructuring of the Meta Quest Unreal Engine developer documentation, reorganizing the information architecture and managing URL migrations with redirect mapping so existing search equity was preserved. I track discoverability using search analytics and developer feedback.
• At Red Hat I worked docs-as-code throughout: AsciiDoc source in Git, changes reviewed as merge requests, and builds run in CI. I set up style linting in the build pipeline, with Python scripts checking cross-references and broken procedure steps on every merge request.