Team & key-person risk
Who holds the knowledge — and what if they leave?
A company can depend on one or two engineers without anyone saying so. CodeDD reads git history across the estate — every repository in scope — to show who owns the code, whether they are still active, and which areas have no backup.
94%
Of the code written by one person
| Contributor | Status | Share | Domains |
|---|---|---|---|
| Maya Chen | Active · 26 days ago | 94% | Data · API · App |
| Luis Ortega | Left · 5 months ago | 2% | DevOps |
Trusted by
Beyond the org chart
A headcount is not a team.
The org chart may say twelve engineers. The code may say that one of them wrote almost all of it.
Ownership, from the code
The share of the codebase each person wrote, with the same person counted once across every repository.
Still here, or gone
A commit in the last 90 days counts as active. A high-share author who stopped committing is the departed-lead case.
Backup, area by area
For each technical area: how many people are still active in it, and whether the load per person is sustainable.
Concentration
What one person carries.
The top owner's share of each repository and of the estate. Two product repositories at more than 90% is a different risk from one quiet side project.
Coverage
Two experts can still be one owner.
An area can have two active people and still depend on one of them for almost all of the code. You need both views before calling it resilient.
Maya Chen · Active · what she carries
| Repository | Files | Share of repo | Of estate |
|---|---|---|---|
| cube-command-center | 2,090 | 67% | |
| cube-pipelines | 836 | 27% |
| Area | Top owner | People | Experts |
|---|---|---|---|
| Data Processing | 99% | 2 | 2 active |
Two experts can still be one owner of the files.
The hire plan
Where one more engineer removes the risk.
Every material technical area is checked for enough active experts — two by default — and a sustainable load per person. Gaps turn into an approximate number of hires, so the fix can go into the plan and the budget.
| Area | Active | Code | Per person | Coverage |
|---|---|---|---|---|
| Machine Learning | 1 | 62K | 62K | +1 hire |
| Data Processing | 2 | 20K | 10K | Handover |
| Application Code | 3 | 48K | 16K | Covered |
CodeDD Advisor
Ask what happens if someone leaves
The Advisor combines ownership, activity, and coverage to answer the questions an investment committee asks about the team.
Across the investment cycle
Where it changes the deal
Pre-deal tech DD
Price key-person risk before signing — retention, earn-out terms, or a handover plan for the people the code depends on.
Hold period
Put a second owner on the areas that depend on one person, and watch the concentration come down.
Pre-sale preparation
Show a buyer that the knowledge sits with the team, not with the founder or one senior engineer.
FAQ
Questions
What does the ownership percentage mean?
The share of the audited files each person wrote, by file count. The same person is counted once across repositories, matched by email. 70% and above is Critical, 50–69% High, 30–49% Medium, below 30% Low.
What counts as active?
A commit in the last 90 days. 91 to 365 days is dormant; longer is stale. A departed lead shows up as a high share with a last commit outside the window.
How is coverage per area measured?
Each audited file is labelled with a technical area — application code, data processing, machine learning, API, DevOps, and so on. An area needs a minimum number of active experts (two by default) and a sustainable load, 100k lines per active developer by default. Both thresholds can be changed.
Are the hire numbers a recommendation?
They are an approximate headcount to close the coverage and workload gaps at your current settings — a planning input, not an offer. Areas under 5k lines are listed but too small to justify a hire on their own.
What about the exit scenario figures?
The app also models what losing the top owner would cost — hiring, handover, and ramp-up time, sized from the code they own and your hourly rate. It is a planning sketch, not a measured outcome; read it after share, activity, and coverage.
Do bots count?
Bot accounts can appear in the ownership ranking if they authored files, so read the human rows for diligence. The coverage and activity views can hide bots.
How is this different from Development activity?
This page is about who holds the knowledge. Development activity is about what the team spends its time on — new product or keeping legacy systems alive.
What data do you store?
Authorship from git — who wrote which audited files, when they last committed — plus the per-area labels and the scores derived from them. Not source code.
See who holds the knowledge in a team you are evaluating
Run it on your repositories yourself, or book a walkthrough of ownership, departures, and where one more hire removes the risk.