Documentation generated from your running product
DocRuntime generates end-user documentation by observing your running SaaS application and its code. When your product changes, your docs update automatically.
Integrates with GitHub, Playwright, and GitBook
The structural problem with documentation
Your product ships weekly or daily. Features change, workflows evolve, and UI states multiply. Documentation, written once and maintained manually, falls behind immediately.
The result is predictable: users encounter interfaces that no longer match the docs. Support volume increases. Trust erodes. Teams debate priorities while the gap widens.
This is not a writing problem or a discipline problem. It is a systems problem. Fast-moving products and static documentation are fundamentally incompatible.
The mismatch compounds over time, creating technical debt in your knowledge layer that no amount of content operations can resolve.
How DocRuntime works
DocRuntime treats documentation as a derived artifact of your product, not authored content. It observes what users can actually do, not what someone wrote about what they should be able to do.
01
Observe the running application
DocRuntime monitors your live SaaS interface, capturing real UI states, user flows, and interactive elements as they exist in production.
02
Connect runtime behavior with code
The system correlates observed UI behavior with your codebase, understanding the relationship between interface elements and their implementation.
03
Generate user documentation
Documentation is synthesized from actual product capabilities, reflecting what users can do rather than what was planned or assumed.
04
Update automatically on change
When your product changes through deployment, DocRuntime detects differences and regenerates affected documentation without manual intervention.
What DocRuntime is not
Not an AI writing assistant
DocRuntime does not help you write documentation. It generates documentation by observing your product's runtime behavior and code structure.
Not a wiki or knowledge base
There is no editor, no authoring interface, and no content management. Documentation is a compilation output, not a manually curated artifact.
Not a documentation editor
You do not maintain content in DocRuntime. You maintain your product. Documentation is derived as a consequence of your product's current state.
Documentation as infrastructure
Traditional documentation is treated as content: authored, edited, reviewed, and published. This model breaks under frequent releases because content cannot keep pace with code.
DocRuntime inverts this. Documentation becomes infrastructure. It is generated from the source of truth—your running application—and maintained through the same deployment pipelines that update your product.
This shift eliminates the maintenance burden. Documentation stays aligned because it is mechanically coupled to the product itself, not dependent on human synchronization.
Built for teams shipping complex products
Product teams
Ship features without coordinating documentation updates. DocRuntime observes changes and reflects them in user-facing docs automatically. Product velocity is no longer constrained by documentation lag.
Support teams
Reference documentation that matches the current product state. No more reconciling discrepancies between what users see and what docs describe. Reduced escalations from documentation gaps.
Engineering teams
Eliminate manual doc syncing from deployment checklists. Documentation updates become a compilation step in your CI/CD pipeline, not a post-release task that gets deferred.
Technical approach
DocRuntime connects to your application through standard integration points. It does not require custom instrumentation or changes to your product architecture.
Runtime observation layer
Uses browser automation frameworks like Playwright to interact with your application as a user would, capturing UI states and workflows systematically.
Code correlation engine
Analyzes your repository to map observed UI elements to their source implementations, establishing bidirectional traceability between interface and code.
Documentation generation pipeline
Synthesizes observations and code analysis into structured user documentation, outputting to formats compatible with GitBook and similar platforms.
Change detection system
Monitors deployments and code commits to identify documentation impact, triggering regeneration only for affected sections to maintain efficiency.
Why this approach is inevitable
Software products are dynamic systems. They change continuously through deployment. Documentation, when treated as static content, cannot match this pace without unsustainable manual effort.
The only sustainable solution is to make documentation a function of the product itself. This requires observing the product at runtime and generating docs from that observation, not from human interpretation.
This is not a novel insight. Infrastructure-as-code, schema-first APIs, and type-driven development all follow the same principle: derive artifacts from source systems rather than maintaining them separately.
DocRuntime applies this principle to end-user documentation. The technical capability exists. The structural problem is well understood. Adoption is a matter of implementation.
Early access program
DocRuntime is currently working with a limited number of design partners. We are focused on B2B SaaS companies with complex UIs, frequent releases, and substantial user bases.
Requirements for participation
Your product must have a web-based interface, active development cycles, and existing end-user documentation. We integrate with GitHub for code access and GitBook or similar platforms for output.
What to expect
Initial integration takes two to three weeks depending on product complexity. You will work directly with our engineering team to configure observation parameters and documentation output formats.
Commitment level
Design partners provide feedback on accuracy, integration workflows, and documentation quality. This is a collaborative development phase, not a finished product evaluation.
Request early access
We are onboarding design partners on a case-by-case basis. If your team faces documentation drift as a structural problem, we would like to hear from you.
Provide your company context, product complexity, and current documentation challenges. We will respond within two business days to discuss fit and next steps.
Limited availability for Q2 2026 onboarding