Two systems, two analyses each
A product a small team still runs, and a system whose builders are long gone. Each shows the map, the evidence, the open questions and what the next analysis changed.
- Example A booking product with a queue An invented booking product run by a small team: a web application, a queue worker, a nightly scheduler and five outside services. The map, three claims and their evidence, four open questions, and what a second analysis a month later reports. What would two analyses of a small product show?
- Example An inherited monolith An invented ten-year-old ordering system bought with a business. What the first analysis establishes, what it says it did not look at, five questions in order of urgency, and how the next two analyses turn the most dangerous of them into facts. What can an analysis establish when the builders are gone?
A project you can open
The demonstration is not a page about an example. It is a project built by the real pipeline from invented input, rendered by the same pages a customer reads.
- Product See an example An analysed demonstration project you can read without an account.
- Product Change history Comparing two analyses of the same system gives four different answers — arrived, changed, gone, and no longer confirmed. Why the fourth one is the reason to keep analysing. How do I track how my system's architecture changes over time?