Why it is a risk
Many companies run on software from one person: a developer on staff, a freelancer or a small agency. While they're around, it works. When they leave, nobody knows how it fits together, or how to put a new version live.
That's not a judgement of that person. It's a risk for your company, and you can measure it.
What we read from your git history
Every change to your code is in the git history, with when and by whom. From it we read, with fixed tools and without AI:
- How old the code is, and how actively it has been worked on over time
- How many people worked on it, and whether most of the work comes from one person. We flag that
- Which files change most often
- Where the complexity is: the parts that are hardest to hand over
- How much test code there is next to the code
What's missing to hand it over
Knowledge that lives only in someone's head belongs on paper. We put your documentation next to a fixed catalogue of what a maintainable application needs. For each item you see whether it's present and current, thin or outdated, or missing. For example:
- How to start the application locally, put a new version live, and roll it back
- The overview of the architecture, the data model and the integrations
- How access and secrets are arranged
- Backups, and how to recover after an outage
What you do with your view
Your view tells the board how big the risk is, and whoever maintains the code where the gaps are. We fix nothing and don't take the work over.
You decide the next step: have documentation written, bring in a second developer to look along, or extend the tests. If a developer works on your software, they get a list with evidence to work from.