All repos appear on left tree menu, but you can also create sites with top menu structure where each menu item directs to subsite with own left menu structure. Examples: https://brodocs.io/94c8be738065bd0c559/Backlog/Intakebacklog..., https://brodocs.io/21a3986b137fb8f4ff8/Backlog/README.html,
Who may like it:
Large organizations to build central and per team documentation sites from micro (and nano) services docs, Terraform/Ansible modules, solution designs, architecture decision records. Keeping docs as markdown in git allows collaboration through standard PR workflows. Could be an input to construct agents.md or copilot-instructions.md in given area, describing architecture at high level, to get better vibe codes. I see quite often that teams build own sites using some static site generator and CI/CD pipelines, moving away from wiki like Confluence, but it costs some effort to build/maintain and security is missing.
Small distributed teams working on startups to have common docs space built from markdown files stored close to source code. When hiring starts, new people need to be on boarded quickly.
Individuals who use PKM (Personal Knowledge Management) tools based on markdown, such as VS Code, NeoVim, Obsidian, or Logseq. If you have spent some time to build PKM, you might be using it in read-only mode for some stable parts, so e.g. in restrictive corporate environments where your favorite PKM tool might not be allowed, or don't want to have too many VSC windows open, quick access from a browser could be helpful.
The MVP does not require signing up. Login and management app will come next.
Happy to hear observations, criticism, and suggestions. How do you prefer to write tech docs at your work, wiki or markdowns in git repo? Do you publish them using some static site generators?