The Statewave team has kicked off a new public build log, titled "Statewave Guide," starting on September 28, 2026. This series documents the creation of an in-app help system designed to derive product knowledge directly from source code, rather than relying on separate documentation bases. The project aims to answer a fundamental question for developers: Can source code become reliable product knowledge without anyone maintaining a knowledge base beside it?

The Problem With Traditional Docs

According to the Day 0 post, the team sought a help chat that truly understands how the product works. They found existing solutions—such as chat frameworks, product-tour libraries, and RAG systems—lacked the ability to connect source code to real-time guidance inside the application. A key frustration was the need for developers to maintain a "second copy" of the app in tools like Confluence just so an assistant could understand the first one. The Statewave approach treats the existing codebase—routes, forms, endpoints, schemas, permissions, tests, translations, and Git history—as the primary source of truth.

Building in Public on GitHub

The project is being developed openly on GitHub, with the repository located at github.com/smaramwbc/statewave-guide. The team has already completed 16 build days, and the code is available for inspection. The blog series will run one or two days a week, detailing the "why" behind the code. The launch strategy involves a coordinated release across dev.to, Hashnode, X, and LinkedIn, with the blog post serving as the central hub. The team explicitly decided against a pre-launch announcement week, making Day 0 the official start of the project's public narrative.

Key Takeaways

  • The Statewave Guide project launches on September 28, 2026, with a focus on deriving product knowledge from source code.
  • The team rejects the need for secondary documentation stores, aiming to use the codebase itself as the knowledge base.
  • The project is open source and visible on GitHub, with a 16-day build history already in place before the first blog post.
  • Future posts will explore the technical challenges, such as distinguishing runtime DOM evidence from the actual product model.

The Bottom Line

This is a refreshing take on AI-driven documentation that refuses to treat the codebase as a black box. For developers tired of maintaining parallel documentation systems, watching this build log unfold is a must.

What's Next

Day 1 of the series, titled "The DOM is not the product," is scheduled for Wednesday, September 30, 2026. This post will delve into the technical realization that the Document Object Model (DOM) is merely runtime evidence, not the product model itself. The team will discuss how they moved beyond simple DOM inspection to map user actions to backend services, such as tracing a button click to a POST /api/clients request. This evolution highlights the complexity of building a guidance engine that is both accurate and maintainable.