You are about to double traffic, double the team, or double the number of integrations. The system that felt fast and simple at your current size is about to be tested by conditions it was never designed for. And here is the uncomfortable part: most scalability failures are not discovered in production under load. They are already visible in your codebase, your data model, and your infrastructure — you just have not looked with the right lens yet.
A software architecture review is that lens. Not a code review, not a security audit, not a performance benchmark — a structured pass over the decisions that are expensive to change later. Done before scaling, it turns a vague sense of risk into a prioritised list of fixes you can schedule, budget, and defend to your board.
This is the process we use with founders and CTOs who are preparing to grow. It is deliberately repeatable, so you can run it every time the business hits a new inflection point.
Key takeaways
- A pre-scale review focuses on the decisions that are costly to reverse: service boundaries, data ownership, state, and infrastructure assumptions.
- Coupling — not raw code quality — is the most common reason a custom system stops scaling smoothly.
- You can run the review in days, not months, if you time-box each area and demand evidence rather than opinions.
- The output should be a ranked list of interventions with effort, risk, and a clear trigger for each, not a rewrite proposal.
- Some findings should be deferred deliberately; refactoring everything at once is as dangerous as refactoring nothing.
What a software architecture review actually is
An architecture review examines the shape of your system: how responsibilities are divided, how components communicate, where data lives and who owns it, and what assumptions your infrastructure makes about load and failure. It is not an attempt to find every bug or enforce a style guide.
The reason to run one before scaling is economic. Architecture decisions have a long half-life. A poorly named function costs minutes to fix; a poorly chosen data ownership boundary can cost quarters. You want to spend your review effort where the leverage is highest.
Review versus audit versus benchmark
- Code review checks whether a change is correct and maintainable.
- Technical architecture audit checks whether the system's structure matches its current and near-future requirements.
- Load test or benchmark measures how the system behaves under a specific, synthetic condition.
They complement each other, but only the audit tells you whether you are about to scale into a wall. Load tests tell you where the wall is; the review tells you why it is there and how expensive it is to move.
When to run a custom software scalability assessment
Timing matters more than thoroughness. A review run too early produces theoretical findings; run too late, and you are doing incident response instead. The useful triggers are predictable:
- You are planning a step change in traffic, users, or transaction volume.
- You are hiring engineers fast and onboarding is getting slower.
- Deployments are becoming riskier, or releases need more coordination.
- You are adding a major integration, region, or compliance requirement.
- Feature velocity is dropping while headcount is rising.
- You are preparing for due diligence, a funding round, or an acquisition conversation.
If two or more of those are true, schedule the review before you commit to the growth plan, not after.
How to review system architecture for growth: the process
Run the review as a time-boxed engagement with a small group: one or two senior engineers who did not build the area under review, an architect or tech lead, and a product or business stakeholder who can speak to expected growth. Two to five days is usually enough for a mid-sized custom system if you keep the scope tight.
Step 1 — Define the growth scenario
Write down the concrete change you are preparing for: expected order of magnitude in traffic, data volume, concurrent users, team size, and integration count. Every finding later gets judged against this scenario. Without it, the review drifts into generic best-practice commentary.
Step 2 — Map the system as it is
Produce a diagram that shows components, communication paths, data stores, and ownership. Keep it honest — the diagram should reflect what runs in production, not the aspirational version in the onboarding doc. If two engineers draw different diagrams, that disagreement is itself a finding.
Step 3 — Walk the critical paths
Trace your three to five most important user or business flows end to end. For each, note every synchronous call, every shared database, every point where a failure cascades. Critical paths reveal coupling faster than reading code.
Step 4 — Interrogate data
Data is where scaling problems hide longest. Ask: who owns each entity, can two services write to the same table, is there a single source of truth, how is schema change managed, and what happens to in-flight transactions during a deploy? Shared mutable state between components is the single most common growth blocker in custom software.
Step 5 — Interrogate state and statelessness
Identify where session state, caches, and background jobs live. If a component cannot be safely run as multiple instances, horizontal scaling is blocked regardless of how good the code is.
Step 6 — Interrogate infrastructure assumptions
List the assumptions baked into your deployment: single region, single database instance, manual steps, long-running migrations, fixed capacity. For each, ask what breaks first and how you would detect it.
Step 7 — Rank findings by leverage
Score each finding on impact, effort, and reversibility. The goal is a short list of interventions that unlock the most growth for the least disruption — plus an explicit list of things you are choosing not to fix yet.
Technical architecture audit checklist
Use this as a working checklist during the review. It is not exhaustive, but it catches the majority of pre-scale problems in custom systems.
- Coupling: Are components communicating through stable interfaces, or reaching into each other's internals and databases?
- Boundaries: Does each service or module own its data, or is ownership shared and ambiguous?
- Contracts: Are APIs versioned, and can you change one without coordinated releases elsewhere?
- State: Can every component scale horizontally, or are there hidden single points of state?
- Data model: Are the hot tables and queries known, and do indexes match real access patterns?
- Transactions: Are cross-boundary operations handled with sagas or compensation, or with distributed transactions that will not survive scale?
- Failure modes: What happens when a dependency is slow rather than down? Are timeouts, retries, and circuit breakers in place?
- Observability: Can you answer what is slow and why, in production, without adding logging first?
- Deployment: How long is a deploy, what is the rollback path, and are migrations backward compatible?
- Security and tenancy: If you are moving to multi-tenant or enterprise customers, is isolation modelled in the architecture or bolted on?
- Cost: Which components scale linearly in cost, and which scale worse than linearly?
- Team: Can a new engineer ship to production in their first week without tribal knowledge?
If you want an outside perspective on the findings, the review is exactly the kind of engagement our team runs before a build or a scale-up — see our software development services for how that works in practice.
Common findings and what they usually mean
Across reviews, the same patterns recur. Recognising them early saves weeks of debate.
The shared database
Multiple services read and write the same tables. It feels efficient and it is the most common cause of cascading failures. The fix is usually gradual: assign ownership, move writes behind an interface, then split storage only if the growth scenario demands it.
The distributed monolith
Services are deployed separately but must be released together. This is worse than a monolith because you pay the operational cost without the autonomy benefit. Either tighten the boundaries or consolidate.
The synchronous chain
A user request fans out through five services, each waiting on the last. Latency compounds and one slow dependency degrades everything. Introduce asynchronous processing or caching where the business can tolerate it.
The invisible single point
A queue, scheduler, or session store that only runs as one instance. It works until the moment it does not, and it is usually cheap to fix before launch.
When to refactor a custom software architecture
The review should end with a decision, not a document. For each finding, choose one of four responses:
- Fix now — high impact, low effort, or blocking the growth plan.
- Fix at a trigger — defer until a specific metric crosses a threshold, and write the threshold down.
- Design around — accept the limitation and change the product or operational plan instead.
- Replace — rare, expensive, and only justified when the architecture cannot meet the scenario at any reasonable cost.
Most teams over-index on replacement. In our experience, the majority of pre-scale problems are solved by clarifying boundaries, removing shared state, and improving observability — not by rewriting. If you want to sanity-check your conclusions against work we have shipped, our project work covers systems that went through exactly this transition.
Make the review a habit, not a project
The most valuable outcome is not the report. It is the practice of reviewing architecture before each major step change, with the same checklist and the same growth scenario discipline. Teams that do this stop discovering their bottlenecks in production.
Avaton builds and reviews custom software for founders and CTOs, and we are happy to compare notes on your architecture before you scale. If you would like a second pair of eyes, get in touch with our team — the conversation is usually more useful than the document.
Frequently Asked Questions
How long does a software architecture review take?
For a mid-sized custom system, a focused review typically takes two to five days of senior engineering time, split between mapping the system, walking critical paths, and ranking findings. The elapsed calendar time is usually longer because you need access to people who know the system. Larger systems with many services or strict compliance requirements can take several weeks, but the highest-leverage findings usually surface in the first few days.
Who should be involved in the review?
Keep the group small: one or two senior engineers who did not build the area under review, an architect or tech lead, and a business stakeholder who can describe the expected growth. Outside reviewers add value because they have no attachment to past decisions and will ask obvious questions insiders have stopped asking. Avoid turning it into a large committee, which slows the process and dilutes the findings.
Does a review always lead to a rewrite?
No, and it usually should not. Most findings are resolved by clarifying service boundaries, removing shared mutable state, improving observability, and making deployments safer. A rewrite is justified only when the architecture cannot meet the growth scenario at any reasonable cost. Treating every finding as a rewrite candidate is the fastest way to waste a quarter and destabilise a working system.
What is the difference between an architecture review and a scalability assessment?
They overlap heavily. A scalability assessment is a review scoped specifically to growth: traffic, data volume, concurrency, and cost curves. A broader architecture review also covers maintainability, security posture, deployment, and team onboarding. If your immediate concern is growth, run the scalability-focused version first and fold in the wider questions where they affect the growth path.
How do we know when to refactor rather than keep patching?
Refactor when the cost of working around a limitation exceeds the cost of changing it, and when the growth scenario makes the limitation unavoidable rather than merely annoying. Set explicit triggers — a latency threshold, a data volume, a team size — and revisit them on a schedule. Deciding in advance removes the emotion from the decision and stops you from either over-engineering early or firefighting later.
Cover: Photo by cottonbro studio on Pexels