Architecture
How much growth can this architecture carry?
Before you underwrite a growth plan, know whether the architecture can take it. CodeDD rates every repository in the estate on a five-tier scale, from the code itself — and shows which one holds the rest back.
- Estate tier
- T2Moderate-Scale Modular Monolith
- About three times today's load before the architecture has to change.
- Held down by
- legacy-etl
- Tier 1, deployed by hand, and billing reads from it on the critical path.
- What lifts it
- Two changes, one repository
- Automate the legacy-etl deploy and add tracing. The estate then reads Tier 3.
- Tier of each repository
- How it depends on another
- Critical path — a dependency the business runs through
Edge / UIWhat customers touch
- T3
web-app
Service-oriented
- command-centerAPI
- shared-uiLibrary
- T3
Core businessWhere revenue runs
- T3
billing-api
Service-oriented
- legacy-etlData
- T3
command-center
Service-oriented
- billing-apiAPI
- reports-svcEvent
- T3
Shared platformReused across products
- N/A
shared-ui
Library
- N/A
Data & analyticsPipelines and reporting
- T1
legacy-etl
Monolith
Weakest link · holds the estate at Tier 2
- T2
reports-svc
Modular monolith
- legacy-etlData
- T1
Trusted by




The scalability ladder
Architecture, reduced to one number you can defend.
Six readings from the code, one ladder, the same rules on every audit. A higher tier is not a better company — it is more headroom, bought with operational cost. What matters is whether the tier clears the growth plan.
Five tiers · growth headroom
- T1
Low-Scale Monolith
One deployable, one database
about 1.5x
- T2
Moderate-Scale Modular Monolith
Bounded contexts, cache, replicas
about 3x
The sample estate today - T3
Mid-Scale Service-Oriented
A few services, gateway, queue
about 5x
After two fixes on legacy-etl - T4
High-Scale Microservices
Many services, events, autoscaling
about 10x
- T5
Real-Time Ultra-Scale Distributed System
Streams, sharding, multi-region
about 20x
Six dimensions · per repository
Deployment model
How the product ships
Data architecture
One store, or one per service
Communication style
Direct calls, or events
Infrastructure maturity
Containers, IaC, CI/CD
Scaling mechanisms
Autoscaling, caching, sharding
Operational maturity
Tracing, alerting, flags
Detected in the repository
Manifests, infrastructure files, CI config, and source. No interview, no questionnaire.
Scored per dimension
Fixed weights and thresholds on every audit. Thin evidence lowers the score, not the standard.
Capped by prerequisites
A tier needs what it requires. Streaming on a manual deploy is still not Tier 4.
Across the investment cycle
Where the tier gets used
Pre-deal tech DD
Check the growth plan against the architecture. If the plan says ten times and the estate carries three, that gap is the finding.
Hold period
Fund the changes that lift the weakest repository first — they move the whole estate up a tier.
Pre-sale preparation
Show a buyer the headroom for their plan, backed by evidence from the code rather than an architecture diagram.
Technology stack
What the estate runs on — and what needs replacing.
Every declared package, grouped by the layer it runs on, with how far behind the shipped version is and whether it is still maintained. A major version behind is a project; an abandoned package is a replacement.
53
Direct packages · 9 layers
3
A major version behind
1
No longer maintained
Stack layers
- Frontend12 packages
- Backend9 packages
- Databases3 packages
- Data & ML4 packages
- Messaging0 packages
- Infrastructure6 packages
- Tooling11 packages
- Runtime2 packages
- Other6 packages
Declared packages
| Package | Layer | Version lag | Maintenance |
|---|---|---|---|
| django | Backend | Up to date | Active |
| react | Frontend | Minor lag (2) | Active |
| redis | Databases | Major lag (2) | Active |
| marimo | Data & ML | Minor lag (5) | Maintained |
| legacy-soap-client | Backend | Major lag (3) | Inactive |
FAQ
Questions
Is a higher tier better?
No. The tier is how much scale the architecture holds, not how good the engineering is — Tier 4 machinery under a small product is wasted cost and operational risk. Read it against the growth plan: if the business intends to grow ten times and the architecture carries three, that gap is the finding.
How is the tier different from the architecture style?
Style is the shape — monolith, modular monolith, service-oriented, microservices. The tier is the scale that shape currently supports, scored across six dimensions. Two companies can both run microservices and land on different tiers, because one has tracing, autoscaling, and a store per service and the other does not.
How does the estate tier get set?
Repository tiers roll up weighted by size and by the role a repository plays — a central system that everything calls counts for more than an isolated tool. Operational maturity is the exception: it takes the weakest repository the business still relies on, because incidents start at the weak point, not the average.
What does not applicable mean?
Some repositories have no operational scale to rate — libraries, design systems, mobile clients, standalone data pipelines. They are marked not applicable instead of being scored as a weak Tier 1, and they do not pull the estate tier down.
How is the technology stack detected?
From the repository. Manifests give the declared packages, which are classified onto nine stack layers; imports in source show which are actually used. Registries supply the latest version and last release date. Maintenance follows the last release: Active within three months, Maintained within six, otherwise Inactive.
How does this relate to Code quality and Estate map?
Architecture is the shape and the scale it holds. Code quality is how maintainable the code inside that shape is — the two move independently, and clean code in a Tier 1 architecture still hits a wall. Estate map goes deeper into how repositories depend on each other and which of those dependencies are critical.
What data do you store?
The component graph, dependency types, the declared package inventory, and the dimension scores behind each tier. Not source code.
See the tier of an estate you are evaluating
Run it on your repositories yourself, or book a walkthrough of the tier, the repository holding it down, and what the next tier would take.