Find the right path through our documentation services, from first inquiry to final delivery.
A deliverable is a written manual, a documented code structure, or a reference sheet that our editors hand over in a format your team can open and edit. We do not count internal review drafts or meeting notes as final deliverables unless you ask us to formalize them.
When we say we document your codebase, we mean the repositories and branches you point us to at the start of an engagement. If your team adds a new service or moves a module to another repository mid-project, that work falls outside the original scope and is quoted separately.
Once we deliver a document and you accept it, the text belongs to your company. You can adapt it, embed it in your internal wiki, or assign it to new hires. We retain the right to reference the engagement in our catalog unless a separate non-disclosure agreement says otherwise.
We do not write marketing copy, product announcements, or public API guides aimed at external developers. Our work is for internal web development teams that need precise structural documentation. If a page is meant for customers or partners, it is outside this agreement.
Each document includes two structured review rounds. A review round means you send us a consolidated list of comments and we return a revised version. Comments that arrive piecemeal over several weeks are treated as one round only if they are submitted within five working days of the first batch.
A document is considered current if it matches the state of the code at the commit we last reviewed. We record the commit hash and the date in the document header. If your team changes the code after that point, the document is marked as outdated until a refresh is scheduled.
These notes exist to remove ambiguity before work starts. If a term is not defined here, ask us before the project begins rather than assuming a meaning.
Straight answers about how we handle scoping, delivery, and handover for your team's coding manuals.
We begin with a short intake call to map your repository structure, identify the main user flows, and agree on the level of detail. From there we send a scoping note that lists the exact documents we will produce, the sections inside each, and the review milestones. You only approve the scope once it matches what your developers actually need.
We work directly against your staging environment and the current branch. Each manual references real function names, file paths, and configuration keys. When we finish a draft, we run a consistency check against the codebase to catch outdated references. The final handover includes a short maintenance guide so your team can update the docs after the next release.
Yes. For legacy systems we rely on a combination of code reading, database schema inspection, and short interviews with the engineers who maintain the system. We flag any area where we had to infer behavior, so you know exactly which parts need a second look. This approach works even when the original documentation is sparse or outdated.
We deliver structured Markdown files that fit into your existing docs site or repository. Each document follows a consistent template: purpose, architecture context, key flows, code examples, and error handling. If you need a different format, we can also export to HTML or PDF, but Markdown keeps the content easy to review and version.
We sign a mutual NDA before any code is shared. All work is done on your infrastructure or a secure sandbox that you control. We never store code snippets outside the project workspace, and we avoid copying sensitive credentials or internal logic into the documentation unless you explicitly ask for it.
For a focused module or a single service, the first draft usually lands within one to two weeks. Larger projects with multiple interconnected systems take longer because we need to trace the data flow and verify edge cases. We set a clear delivery schedule in the scoping note, so you always know when to expect the next version.
Need a more specific answer? Contact our team or check the support page for common requests.