Development activity
How much of the engineering team is building new product?
CodeDD classifies every commit as new work or maintenance, and identifies stale repositories. A maintenance-heavy development load leaves little capacity for new features, so a growth plan may depend on new hires or on moving off legacy systems first.
38%
New product work
62%
Maintenance
3
Engineers on legacy code
| Repository | Lifecycle | New Work vs. Maintenance |
|---|---|---|
| legacy-etl | Legacy | |
| billing-api | Active | |
| reports-svc | Active |
Trusted by
Beyond a commit chart
See where engineering time goes.
A busy team can still spend most of its time maintaining old systems. CodeDD shows how engineering capacity is split between new work and maintenance, and between core and legacy systems.
New work or maintenance
Each commit is classified as new work or maintenance, so you see how engineering capacity is actually split.
Core or legacy systems
The split of engineering time between core and legacy systems, and whether legacy work adds features or only maintains.
Dormant systems
Business-critical repositories with no recent commits, which may mean nobody is maintaining them.
Where to look first
Critical systems nobody is working on.
A critical system with no recent commits may be missing security fixes, and the people who know it may have left.
Active
Dormant
Stale
High impact
billing-api · legacy-etl—pricing-engineLower
reports-svcdocs-site—pricing-engine: business-critical, no commits in over six months.
The legacy question
Maintain it, or migrate?
See who works on each legacy repository and what they do there. Mostly maintenance means an ongoing cost. New features on a legacy system mean a migration decision is due.
legacy-etl · 3 engineers this quarter
Mostly keeping it running. One person is still building new features on it.
| Engineer | Area | Their work |
|---|---|---|
| Maya Chen | Data | 80% maintenance |
| Sam Okafor | Billing | 70% maintenance |
| Priya Shah | Platform | 55% new features |
Capacity allocation
Size the capacity you can move to growth.
The contributor matrix shows who commits to non-core applications each month. With that data, you can set a floor for legacy maintenance work and see how much engineering capacity it frees up for core product before you plan new hires.
codedd.ai / development activity
Contributor matrix for non-core applications (aggregate)
101 contributors · last 12 monthsMarcus Feldner
Elena Vostrikova
Tomas Berg
Priya Nayar
Daniel Roth
+93 more contributors (names anonymised)
codedd.ai / capacity allocation
Development capacity allocation
Share of total engineering capacity. Legacy maintenance floor of 13% retained to honour active SLAs, illustrative of the engagement.
CodeDD Advisor
Ask questions that combine the data.
The Advisor answers questions that need activity, business impact and vulnerability data together, such as which business-critical repositories have no recent commits and a known vulnerability.
Related products
Where to look next.
Team & Key-Person Risk
A system with no active engineers, or one that depends on a few people, is a continuity risk. See who holds the knowledge in each area, and where one departure would leave a gap.
AI in Development
Maintenance work is often where AI coding tools save the most time. A team with a heavy maintenance load and little AI use has a clear place to start.
Across the investment cycle
Where it changes the plan.
Pre-deal tech DD
Know how much of the team you are buying is available for growth, and how much is tied up in upkeep.
Hold period
Shift capacity from maintenance to the value-creation plan, and show the split moving quarter by quarter.
Pre-sale preparation
Show a buyer an engineering team that builds, with legacy systems retired or deliberately contained.
FAQ
Questions.
How do you decide new work versus maintenance?
Commits are classified from Git signals — messages and the type of change — into new work (features) and maintenance (fixes, chores, upgrades, docs, CI). It is a consistent heuristic across the estate, not a timesheet: use it for the shape of the team's effort, not for a performance review.
What counts as legacy?
A lifecycle label on each repository — the older lines, as opposed to active product. Filter to legacy and read the mix on those repositories to answer whether the company is still building on the old stack or only keeping it alive.
How is this different from Team & key-person risk?
This page shows where effort goes and what has gone quiet. Team & key-person risk shows who holds the knowledge — how concentrated ownership is, and whether each area has enough people.
How is this different from Delivery (DORA)?
Delivery measures how often and how safely the team ships. This page measures what that effort is spent on. A team can ship smoothly and still spend most of its time on maintenance.
Are bots included?
Bot accounts can be hidden, and the default view shows people. Cross-repository views ignore bots, so a CI account never looks like your most connected engineer.
What data do you store?
Git analytics — authors, dates, repositories, areas, and the classification of each commit. Not source code.
See where engineering effort goes in a team you are evaluating.
Run it on your repositories yourself, or book a walkthrough of the split, the legacy systems, and what has gone quiet.