Software Architecture Review
A fixed-scope review of your software architecture
An independent assessment of an existing system - structure, scalability, reliability, security and cost - run by senior architects and delivered as a scored report you can act on.
For engineering and product leaders who need an outside view of a system before they scale it, fund it, or hand it to someone else.
Powered by Comtau Inc.
Architecture review · scorecard
Illustrative report outline
- Structure & modularitywatch
- Scalabilityrisk
- Reliabilitywatch
- Securityok
- Data architecturewatch
- Cost & efficiencyok
- Maintainabilitywatch
- Team & process fitrisk
Roadmap
- Scope
- Fixed, agreed before the review starts
- Output
- Scorecard, risk register and roadmap
- Next step
- A short scoping call
Review, assessment, or code audit?
A software architecture review is an independent evaluation of how a system is structured - its boundaries, its scalability and reliability characteristics, and the risk it carries - measured against what the business needs it to do next.
It differs from a code audit, which looks at code-level quality and security rather than the wider structure. It differs from a technical debt assessment, which measures the cost of past shortcuts across code, architecture and delivery process. And it differs from technical due diligence, which is the investor-side version of a review, run ahead of a funding or acquisition decision.
- Architecture reviewIndependent evaluation of structure, scalability, reliability and risk
- Answers: Will this structure carry what the business needs next?
- Output: Scorecard, risk register, roadmap
- Code auditNarrower: code-level quality and security, not the wider architecture
- Answers: Is the code itself sound and secure?
- Output: Code-level issue list
- Technical debt assessmentMeasures the cost of shortcuts across code, architecture and process
- Answers: What are past shortcuts costing us, and what do we fix first?
- Output: Debt register and remediation roadmap
- Technical due diligenceThe investor-side review, run ahead of a deal
- Answers: Is this technology a risk to the deal?
- Output: Investor-facing risk report
When to request one
When an outside view of the architecture earns its cost
A review is most useful when a decision depends on knowing what the system can actually take on next.
- 01
Scaling into a wall
Load, data volume or team size are outgrowing decisions made early on.
- 02
A fundraise or investor questions ahead
Technical risk needs to be understood before someone else finds it first.
- 03
Performance or reliability incidents
Incidents keep recurring and the root cause is architectural, not a single bug.
- 04
New leadership taking over the system
A new CTO, architect or engineering leader needs an honest baseline, fast.
- 05
A major re-platform or AI feature underway
A significant change is planned and the current architecture hasn’t been stress-tested against it.
- 06
Delivery slowing down without a clear cause
Release velocity is falling and it isn’t obvious whether the cause is process or architecture.
What we assess
Eight areas, each with concrete checks
Every area produces specific findings, not a general impression. Areas relevant to AI or data-heavy systems are assessed alongside the rest, not as an afterthought.
8 areas · 27 checks
Evidence:InterviewsCodeMetricsDocs
01Structure & modularity4
How the system is decomposed and where its boundaries actually sit
- Do module boundaries follow business capabilities?
- Do dependencies point one way, without cycles?
- Can one part change and deploy without touching others?
- Is a shared database or library coupling teams together?
→ Module and boundary map · Coupling hotspots · Dependency-direction check
Evidence: Code · Docs · Interviews
02Scalability4
Whether the architecture can absorb the load, data and team growth you expect
- Which component saturates first as load or data grows?
- Is state held where it blocks horizontal scaling?
- Are heavy workloads isolated from user-facing paths?
- Has the system been load-tested against expected growth?
→ Scaling limits by component · Bottleneck list · Growth headroom estimate
Evidence: Code · Metrics · Interviews
03Reliability4
Failure modes, recovery paths and single points of failure
- What happens when each dependency is slow or down?
- Which single points of failure have no fallback?
- Are backup and recovery tested, not just configured?
- Do recurring incidents share a structural root cause?
→ Failure-mode list · Recovery-path check · Single-point-of-failure register
Evidence: Metrics · Docs · Interviews
04Security3
Architecture-level security posture, not a penetration test
- Where are the trust boundaries, and are they enforced?
- How are identity, access and secrets handled across services?
- Which data and interfaces are exposed, and to whom?
→ Trust-boundary review · Access-control check · Exposure list
Evidence: Code · Docs
05Data architecture3
How data is modelled, owned and moved, including any AI or ML components
- Does each dataset have one clear owner?
- Where can data diverge as it moves between systems?
- Are AI/ML data, evaluation and model versions managed?
→ Data-ownership map · Integration and pipeline check · AI/ML component readiness note
Evidence: Code · Docs · Interviews
06Cost & efficiency3
Where the architecture spends money it doesn’t need to
- Which components drive most of the infrastructure spend?
- Does cost grow in line with usage?
- Where are resources provisioned but idle?
→ Cost-driver list · Efficiency opportunities
Evidence: Metrics · Docs
07Maintainability & evolvability3
How easily the system can absorb the next two years of change
- Where is change most expensive, by churn and defects?
- Is test coverage strongest where risk is highest?
- Is architecture knowledge written down or held by one person?
→ Change-cost hotspots · Evolvability notes
Evidence: Code · Metrics · Interviews
08Team & process fit3
Whether the architecture matches how the team is organised and delivers
- Do team boundaries match system boundaries?
- Can teams release independently?
- Does the delivery process support where the architecture needs to go?
→ Team/architecture fit check · Delivery-process observations
Evidence: Interviews · Metrics
Method
How the review runs
A structured three-stage process, not an open-ended engagement.
Stage 1Prepare
Agree the goals, scope and the quality attributes that matter most, and get access to what we need.
- Goals and the decisions the review must inform
- Scope and quality-attribute priorities
- Access and NDA
- Intake of existing docs and diagrams
- Inputs
- Your goals, access, existing documentation
- Outputs
- Review scope · Confirmed priorities
Stage 2Assess
Interviews, a code and infrastructure walkthrough, and scenario-based trade-off analysis against real situations the system has to handle.
- Interviews with leadership and engineers
- Code and infrastructure walkthrough
- Scenario-based trade-off analysis, in the spirit of ATAM
- Risk storming with the team
- Inputs
- Interview time, walkthroughs, delivery and runtime data
- Outputs
- Working notes · Risk log
Stage 3Report
Findings are scored, prioritised and walked through with your team in a read-out session.
- Findings scored per area
- Risks rated by severity and likelihood
- Recommendations sorted into now, next and later
- Read-out session with leadership and team
- Inputs
- Validated findings and agreed priorities
- Outputs
- Scored report · Prioritised roadmap
Deliverables
What you receive
The review ends in a report your team can act on, not a slide deck.
Architecture review report
Illustrative format · not client findings
Scorecard · 8 areas
- Structure & modularitywatch
- Scalabilityrisk
- Reliabilitywatch
- Securityok
- Data architecturewatch
- Cost & efficiencyok
- Maintainabilitywatch
- Team & process fitrisk
Risk matrix
↑ severitylikelihood →
Risk register
- R-01Reporting queries run against the same database as checkout.Area: ScalabilitySeverity × likelihood: High × HighHorizon: Now
- R-02One team owns three unrelated services, slowing every cross-cutting change.Area: Team & process fitSeverity × likelihood: Medium × HighHorizon: Next
- R-03Two core services share tables, so neither can change its schema alone.Area: Structure & modularitySeverity × likelihood: Medium × MediumHorizon: Later
Prioritised roadmap
- NowContain the highest-severity risks
- NextStructural changes, planned into delivery
- LaterBundle with the target architecture
Findings report
Each finding tied to an area, the evidence behind it and the business risk it creates.
Architecture scorecard
All eight areas rated on one page, so leadership sees the shape of the risk at a glance.
Risk register
Risks rated by severity and likelihood, with an owner-ready recommendation for each.
Prioritised recommendations
Grouped into now, next and later, so work can start without waiting for a rewrite.
Target-architecture sketch & roadmap
Where the system should go, and the order of the steps to get there.
Read-out workshop
Findings walked through with your leadership and team, with questions answered in the room.
Format
Format, timeline and effort
The review is a fixed-scope engagement, not an open retainer. Its length depends on the size and complexity of the system being reviewed, and is agreed before it starts.
What we need from you
- Read access to the codebase, infrastructure and architecture documentation you already have
- Time from two to four people for interviews and walkthroughs
- A short read-out session with your leadership team once the findings are ready
Duration is agreed at scoping, based on the size and complexity of the system.
Review variants
The same method, scoped to your situation
Startup architecture audit
- Common situation
- A startup preparing for a fundraise or a first real scale-up, with a codebase built quickly.
- Main CTO focus
- Whether the architecture will hold under growth, and what an investor would ask about first.
- Outcome
- A clear, defensible answer to “is the technology a risk to this round?”
Application / system audit
- Common situation
- One product or system that needs an outside, independent view.
- Main CTO focus
- The full eight-area assessment against that system’s own goals and constraints.
- Outcome
- A scored report and a roadmap your own team can execute.
AI-system architecture review
- Common situation
- An AI or LLM-based feature or product moving toward production.
- Main CTO focus
- Model and data architecture, evaluation, cost and the same structural checks as any system.
- Outcome
- Confidence the AI component is built on a foundation that can scale and be governed.
Ready to scope a review?
Tell us about the system and what’s driving the question, and we’ll come back with a fixed scope.
Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.
After the review
Review, decide, execute
A review is deliberately independent. What happens with the findings is your decision, and Comtau can help with any of the paths below.
- You are hereReview
- Execute
Ongoing architecture consulting
For a system that needs continued design work, not just a diagnosis.
Learn more - Execute
Technical debt remediation
For findings that are mostly about accumulated shortcuts rather than structural risk.
Learn more - Execute
Execution support
For teams that want the reviewers to stay hands-on while the roadmap is implemented.
Talk to us
- Execute
Considering a deal rather than an internal decision? See technical due diligence, the investor-side version of this review.
How a finding becomes a fixed system
The review is scoped and independent. If you want Comtau to stay involved, the report is not re-interpreted later: each output below is the direct input to the next step.
Assessment
Examine the system across the eight areas, from structure and security to team and process fit.
Output
- Gate
- Each score backed by what was examined
- Why it lowers risk
- Scores rest on what was examined, not on impressions.
Output becomes the input to Findings and risk map
Findings and risk map
Turn the scores into findings, each rated by severity and tied to a business risk.
Output
- Gate
- Walked through with you in the read-out
- Why it lowers risk
- You see which risks matter to the business first.
Output becomes the input to Architecture decisions
Architecture decisions
After the review, if you choose
Decide how each material finding will be addressed, with the options and trade-offs written down.
Output
- Gate
- Each decision approved by a person
- Why it lowers risk
- Nothing is built on a decision nobody made on purpose.
Output becomes the input to Remediation plan
Remediation plan
After the review, if you choose
Break the decisions into bounded units of remediation work, in risk order.
Output
- Gate
- Order and scope agreed
- Why it lowers risk
- Work cannot quietly grow beyond what was agreed.
Output becomes the input to Controlled remediation
Controlled remediation
After the review, if you choose
Implement unit by unit, AI-assisted and human-controlled, and re-check each against the finding it closes.
Output
- Gate
- Checks and independent review per unit
- Why it lowers risk
- A finding is closed when it is proven fixed, not when a ticket moves.
FAQ
Architecture review questions
What does an architecture review include?
An assessment across eight areas - structure, scalability, reliability, security, data, cost, maintainability and team/process fit - delivered as a scored report with a prioritised roadmap and a read-out session.
How is this different from a code audit?
A code audit looks at code-level quality and security. An architecture review looks at the wider structure: boundaries, scalability, data flow and risk, measured against what the business needs the system to do.
How long does a review take?
It depends on the size and complexity of the system. The scope, and the time it will take, are agreed before the review starts - see format, timeline and effort.
What does it cost?
Cost follows scope and complexity rather than a flat rate. See fractional CTO cost & engagement models for how Comtau structures engagements more generally.
Do startups need this, or only larger companies?
Startups commonly request it ahead of a fundraise, when technical risk needs an honest, independent answer before an investor asks the question first.
What access do you need from us?
Read access to the codebase, infrastructure and any existing architecture documentation, plus time from a few people for interviews. Nothing is required beyond what is needed to do the assessment.
What happens after the review?
You decide. Some teams take the roadmap and execute it themselves. Others continue into architecture consulting or technical debt remediation with Comtau.
Get an independent read on your architecture
Tell us about the system and what’s driving the question. We’ll agree a fixed scope for the review and tell you plainly what it will and won’t answer.
Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.
What happens next
- 01You describe the system and the decision behind the request
- 02We agree the scope, access needed and the areas to prioritise
- 03You receive a scored report, a roadmap and a read-out session
Talk to a senior CTO/architect
Book a call