Estate map
Which system can the business not run without?
CodeDD rebuilds how the estate — every repository in scope — fits together, from the code itself: the role each system plays, how they depend on each other, and the one everything runs through.
- The estate
- 9 repositories, 5 roles
- Two sit in core business, where the revenue runs.
- 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
Edge / UIWhat customers touch
web-shop
Storefront
- checkout-svcAPI
partner-portal
Partner self-service
- billing-apiAPI
- auth-libLibrary
Core businessWhere 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
Integration adaptersLinks to third parties
stripe-adapter
Card payments
erp-sync
Finance system sync
- ledger-coreEvent
Trusted by




If it fails
Four systems stop when ledger-core does.
Checkout, invoicing, revenue reporting, and the finance sync all depend on it directly. That is the finding a board can act on — isolate it, or accept the concentration.
If it fails
ledger-core
Accounts and payments · Shared platform
4 repositories depend on it directly, across 3 business roles
checkout-svc
Online checkout · Core business
APIbilling-api
Invoicing · Core business
Datarevenue-etl
Revenue reporting · Data & analytics
Dataerp-sync
Finance system sync · Integration adapters
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
A Git host shows repositories. The estate is the relationships.
The architecture of a company lives between repositories — who calls whom, who shares a store, who publishes the library everyone imports. Those links are not in the org chart, and they are not on a whiteboard that is still true.
What Git shows
- web-shop
- partner-portal
- checkout-svc
- billing-api
- ledger-core
- auth-lib
- revenue-etl
- stripe-adapter
- erp-sync
Nine repositories. Nothing in the list says which one checkout cannot run without.
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.