The more technical the organization, the more likely it asks this: "Couldn't we just build it ourselves with an LLM?" You could. A prototype is achievable. That is how we started too. The problem is the distance between a prototype and infrastructure.
A prototype is easy. Production is another job
- Languages. A parser for one repo in one language is easy. A real company has Java and TypeScript and Python and ten-year-old PHP mixed together, and each language needs its own analyzer.
- Connections. Code is not a clean tree. It is a graph with cycles in it. Repositories connect to each other through API calls and config strings, not imports. Miss that and you get a pile of fragments instead of a map.
- Freshness. Maintaining it is harder than building it. You need a pipeline that detects dozens of commits a day and re-analyzes only the affected scope. Without that, it starts going stale the day it is finished.
- Trust. Evidence links, explicit gaps, confidence levels. Without these honesty mechanisms, all you get is one more plausible-sounding internal chatbot.
The real cost is opportunity cost
The people who can build this are the engineers who know your systems most deeply. While they build internal tooling, who builds the product customers pay for? The bill for building it yourself does not arrive as development cost but as your best people's time. And the moment its authors leave, the tool becomes legacy nobody can maintain. A tool built to untangle legacy becomes the next legacy.
No company builds its own version control
No company builds its own Git, and none writes CI/CD from scratch. What every team eventually needs is infrastructure, and infrastructure is bought. System context goes the same way. An organization's energy belongs on what it builds on top of the infrastructure, not on reinventing it.