Architecture
Can the architecture carry the growth plan?
A growth plan assumes the software will scale. CodeDD rates each repository on a five-tier scale from the code, and shows which one could be a risk factor to growth.
- Company tier
- T2Moderate-Scale Modular Monolith
- Bounded contexts, a cache and read replicas.
- Limited 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 company then reaches Tier 3.
- Tier of each repository
- How it depends on another
- Critical path — a dependency the business runs through
Customer-facingWhat customers touch
- T3
web-app
Service-oriented
- command-centerAPI
- shared-uiLibrary
- T3
Revenue systemsWhere 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 · limits the company to Tier 2
- T2
reports-svc
Modular monolith
- legacy-etlData
- T1
Trusted by
The scalability ladder
The same scale for every company, set by evidence in the code.
The tier replaces a reviewer's opinion with six readings from the code, scored consistently on every audit. The score applies in context: a higher tier is not better, and what matters is whether it covers the growth plan.
Five tiers
- T1
Low-Scale Monolith
One deployable, one database
- T2
Moderate-Scale Modular Monolith
Bounded contexts, cache, replicas
The sample company today - T3
Mid-Scale Service-Oriented
A few services, gateway, queue
After two fixes on legacy-etl - T4
High-Scale Microservices
Many services, events, autoscaling
- T5
Real-Time Ultra-Scale Distributed System
Streams, sharding, multi-region
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
Technology stack
What the company runs on, and what needs replacing.
Outdated and abandoned packages become upgrade projects after close. CodeDD lists every package by layer, with its version lag and whether it is still maintained.
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 shows how much scale the architecture supports. Tier 4 infrastructure under a small product adds cost and operational risk. Compare the tier with the growth plan: if the business plans to grow ten times and the architecture supports three, that gap is the finding.
How is the tier different from the architecture style?
Style is the shape: monolith, modular monolith, service-oriented or microservices. The tier is the scale that shape currently supports, scored across six dimensions. Two companies can both run microservices and reach different tiers, because one has tracing, autoscaling and a store per service and the other does not.
How is the company's tier set?
Repository tiers are combined, weighted by size and by the role each repository plays, so 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 weakest point.
What does not applicable mean?
Some repositories have no operational scale to rate, such as libraries, design systems, mobile clients and standalone data pipelines. They are marked not applicable instead of being scored as a weak Tier 1, and they do not pull the company's tier down.
How is the technology stack detected?
From the repository. Package manifests list the declared packages, which are sorted into nine stack layers, and imports in the source show which ones are used. Package registries give the latest version and release date. A package is Active if it had a release in the last three months, Maintained within six months, and Inactive after that.
How does this relate to Code quality and Estate map?
Architecture is the shape of the system and the scale it supports. Code quality is how maintainable the code inside it is. The two are independent: a Tier 1 architecture with clean code still cannot carry much growth. Estate map shows 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. Source code is not stored.
See how much growth a company's architecture can carry.
Run it on your own repositories, or book a walkthrough of the tier, the repository that limits it, and what it takes to reach the next tier.