Four Products, Four Different First Questions
How to route an engineering problem without pretending every Kalu Kode product is interchangeable.
Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.
Product families are easy to explain as a diagram and harder to explain in a first conversation. Someone arrives with a deployed application, a messy repository, or a lost decision trail. Which product should they ask about?
Our preferred starting point is the question they need answered, not the largest possible bundle of tools. The products share an evidence-oriented approach, but their inputs, responsibilities, and maturity are not interchangeable.
What did the browser actually receive?
That is a KodeCapture question. The useful output is acquisition evidence and bounded replay, with an honest account of what was observed and what remains unavailable. Capture should not silently become a source-editing operation simply because the eventual goal is recovery.
A team preserving an authorized interactive frontend might begin here even when it does not yet want a maintainable source project. The immediate problem is preserving a reviewable observation before the deployment changes.
Can this become an editable, inspectable candidate?
That is a KodeBack question. It includes source evidence, dependency identity, candidate ownership, and controlled comparisons. The desired outcome must still be scoped. Reconstructing maintainable frontend code is not reconstructing an unseen backend or retrieving the exact private development history.
KodeBack and KodeCapture are our active product focus. Current discussions should begin with fit and a bounded evaluation rather than assume a general-purpose, self-service recovery promise.
What changed, and what should remain true?
KodeProof addresses bounded change-safety questions, but its development is frozen in the current engineering direction. Its research can inform a conversation without becoming an active release claim.
KodeAtlas addresses software memory over time. Its website separates the archive CLI from context-platform work in development and coordination or memory features that remain planned. That distinction is important: archive capture is not the same as an implemented historical reasoning platform.
The first conversation should therefore end with one primary question and one appropriate owner. An evidence chain can connect products later, but it should not erase the boundaries that make each result understandable.
Use our contact page to describe the decision you need to make. A non-confidential summary is enough to begin. We would rather route a narrow problem correctly than sell a broad story that leaves the engineering work undefined.