Estate map
Find the system everything else depends on.
CodeDD maps how every repository in scope fits together, using the code itself: the role each system plays, how the systems depend on each other, and the single point of failure they all run through.
- The estate
- 9 repositories, 5 roles
- Two are revenue systems.
- Dependencies
- 8 found, 4 critical
- Each one traced to a file in the code, with a confidence.
- Choke point
- ledger-core
- Checkout, invoicing, reporting, and finance sync all depend on it directly.
- Row · the role it plays for the business
- How it depends on another
- Critical path — a dependency the business runs through
- Many repositories depend on it
Customer-facingWhat customers touch
web-shop
Storefront
- checkout-svcAPI
partner-portal
Partner self-service
- billing-apiAPI
- auth-libLibrary
Revenue systemsWhere revenue runs
checkout-svc
Online checkout
- ledger-coreAPI
- stripe-adapterAPI
billing-api
Invoicing
- ledger-coreData
Shared platformReused across products
ledger-coreChoke point
Accounts and payments
auth-lib
Shared sign-in
Data & analyticsPipelines and reporting
revenue-etl
Revenue reporting
- ledger-coreData
Third-party integrationsLinks to outside services
stripe-adapter
Card payments
erp-sync
Finance system sync
- ledger-coreEvent
Trusted by
Outage impact
Four systems stop when ledger-core does.
Checkout, invoicing, revenue reporting and the finance sync all depend on it directly. Management can see how far an outage would spread and where to reduce the risk, for example by adding redundancy or decoupling the systems that rely on it.
If it fails
ledger-core
Accounts and payments · Shared platform
4 repositories depend on it directly, across 3 business roles
checkout-svc
Online checkout · Revenue systems
APIbilling-api
Invoicing · Revenue systems
Datarevenue-etl
Revenue reporting · Data & analytics
Dataerp-sync
Finance system sync · Third-party integrations
Event
Fix firstIsolate ledger-core: timeouts and a fallback on its four callers, and a runbook for when it is down.
How the map is built
Turn a list of repositories into a map of dependencies.
Diagrams go out of date. CodeDD reads the links between repositories from the code and shows the file behind each one.
What Git shows
- web-shop
- partner-portal
- checkout-svc
- billing-api
- ledger-core
- auth-lib
- revenue-etl
- stripe-adapter
- erp-sync
Nine repositories. The list does not show which one checkout depends on.
What CodeDD reads
API calls
HTTP clients and contracts that cross a repository boundary
Events
Topics one repository publishes and another subscribes to
Shared data
Stores one repository owns and another reads or writes
Internal libraries
Packages published in one repository and imported in another
checkout-svcdepends onledger-coreAPI
checkout/src/payments/ledgerClient.ts
POST /v1/entries { account, amount }Confidence · 94%
Across the investment cycle
Where the map changes the plan.
Pre-deal tech DD
Find the concentration risk management did not mention — the one system checkout, billing, and finance all depend on.
Hold period
Isolate the choke point before it becomes an outage, and plan carve-outs or integrations on the real dependencies.
Pre-sale preparation
Hand a buyer an architecture picture that is true on the day of the data room, backed by evidence in the code.
FAQ
Questions.
How is this different from Architecture?
Architecture scores how much growth each repository's current shape can absorb. Estate map shows how those repositories connect, the role each one plays, and which of those connections the business cannot run without. You need both: a clean Tier 3 service that everything else calls is still a concentration risk.
How are the relationships found?
From the repositories. HTTP clients and API contracts, event declarations and subscriptions, shared stores, and internal library imports. Each edge keeps a file, a line, and a confidence. Not from interviews, and not from a diagram someone drew last year.
What does a business role mean?
The job the repository does for the company — customer surface, revenue system, shared platform, reporting, third-party adapter. It is inferred from the code and the dependencies, then placed on a lane. It is not the Git folder name and not the org chart.
What is a critical path?
A dependency the business cannot run without. If checkout cannot complete when ledger-core is down, that API call is critical. Other links — a shared design system, a reporting subscriber — stay on the map but do not get that mark.
What is a choke point?
A repository many others depend on directly. High fan-in. If it fails, several business roles stop. The map names it so a board can decide to isolate it, fund a fallback, or accept the concentration.
Can a management architecture diagram replace this?
It can start the conversation. It cannot stay true. Relationships change with every merge, and the load-bearing ones are often the ones nobody put on the slide. The map is rebuilt from the code on each audit.
What data do you store?
The graph: repositories, roles, relation types, and the evidence pointers behind each edge — file, line, confidence. Not source. Cloud audits overwrite raw source after analysis.
See the map of an estate you are evaluating.
Run it on your repositories yourself, or book a walkthrough of the roles, the dependencies, the choke point, and the evidence behind each line.