Getting Started
Overview
Dev-Doc turns a source-code repository into the documentation an organisation is expected to have but rarely does: a project overview, a module map, a full C4 architecture model, stakeholder canvases, architecture decision records and — optionally — a plain-language explanation of every file and function.
It works on modern and legacy code alike. COBOL, PL/SQL, T-SQL and decades-old Java or C are documented with the same depth as a modern web stack, and mixed-language repositories and monorepos are supported — each module is detected separately.
How Dev-Doc is different
- Facts first, prose second. Modules, deliverables, entry points, declared dependencies, deployment services and call relationships are read from the code and build files before any text is generated.
- An audit after every run. A deterministic check compares the generated documents with the source tree — invented identifiers, missing files, wrong signatures, misplaced components — and records what is new and what was resolved.
- Human approval survives regeneration. Sections your team has edited or approved are kept when the code changes; the rest is refreshed.
- Read-only. Nothing is installed alongside your code and nothing is written back to the repository.
What you get
| Tab | Answers | Contents |
|---|---|---|
| Overview | Where? | Summary, architecture narrative, modules, API surface, tech stack |
| Architecture | What? | C4 diagrams: context (L1), containers (L2), components (L3), code (L4) |
| Governance | Why? | Inception canvas, communication canvas, ADRs, configuration records |
| Codebase | How? | Explanations per file, class and function (optional) |
| Quality | — | Requirements traceability and verification evidence (where enabled) |
Everything can be downloaded as Markdown, as an arc42 document (also AsciiDoc for docToolchain) and with an SBOM pack for Cyber Resilience Act and NIS2 reviews — see Download & export.
Next: Your first project.