What Happens During an Architecture Review
Before we write a line of product code, we spend two to three weeks pressure-testing the system on paper. This is the actual process — and a worked example, start to finish.
A review of decisions, not a document for show
An architecture review answers one question: will this system survive contact with real load, real markets and real change — before it is expensive to find out. It is run by senior engineers and an architect, at firm level. Here is the boundary.
What it is
- A working session on the decisions that are hard to reverse later — data model, request paths, where state lives, failure modes.
- A load and risk model: the system imagined at 10x launch-day traffic, with the breakages named.
- A written record — every major call captured as a decision, with the reasoning, so it survives team changes.
What it isn't
- A diagram drawn to look impressive and then filed away.
- A rubber stamp on whatever was already decided.
- A sales artifact. If the right answer is "don't build this yet," that is what we will tell you.
Five stages, two to three weeks
Each stage produces something concrete. Nothing here depends on a client saying yes — it is the same sequence every time.
Discovery
Days 1–3We map the product goals, the constraints, the launch markets and the decisions already made — so the review pressure-tests reality, not a wish list.
System mapping
Days 3–6We draw the current or intended system end to end: data flows, third parties, every request path, and exactly where state lives.
Risk & load review
Week 2We model the system at 10x launch-day load and hunt the failure modes: single points of failure, blocking work in the request path, data-residency gaps.
Trade-off decisions
Week 2Each major call is recorded as a decision: the context, the options we considered, the choice and what it costs us later. No decision is left implicit.
Sign-off & handoff
End of week 2–3We walk you through the whole picture and hand over the artifacts. You own them — whether you build with us or not.
A B2B SaaS, scaling into three markets
A B2B SaaS product, roughly 25,000 monthly active users, live in one country and preparing to open in two more — one in the EU. Growth is healthy, but the team is feeling it: report exports time out at month-end, and a marketing push last quarter pushed response times into the seconds. They came to us before committing to a rebuild.
The brief sounded like a scaling problem. The review found it was an architecture problem — the load was simply making it visible. Here is what the system looked like, and what we proposed.
Before — what we found
One process doing everything, one database, one region.
After — what we proposed
Heavy work moved off the request path; data layer and regions split.
The decision we didn't make
The obvious move was "go microservices." We didn't. This is the actual decision record from the scenario above — the format we use for every call that is hard to reverse.
- Full microservices — independent scaling, but distributed transactions, new ops burden, and a much slower path to launch.
- Modular monolith + async workers — move heavy work off the request path, add replicas and a cache, keep one deployable.
- Do nothing, add servers — buys weeks, not a launch.
Six artifacts you keep
Tangible documents you own at sign-off — whether or not we build the product together.
Architecture diagram
The system end to end — request paths, data flows, third parties and where state lives.
Risk register
Every failure mode we found, ranked by likelihood and blast radius, each with a mitigation.
Decision log (ADRs)
The hard-to-reverse calls, recorded with context, options and consequences — like ADR-014 above.
Scalability model
How the system behaves at 10x load, where it bends first, and the order in which to reinforce it.
Cost-to-scale view
A realistic read on what running this will cost as you grow — so infrastructure isn't a surprise.
Phased roadmap
What to build first, what can wait, and the sequence that keeps you shippable throughout.
The point is the rewrite that never happens
the load we model for — launch day is not the stress test.
residency, failure modes and cost are decided up front — not after a fine or an outage.
costly rewrites is the goal — the expensive mistakes get caught on paper.
What we need from you
The review is only as sharp as its inputs. To get the most from it, we ask for a few things up front — and we are explicit about what falls outside its scope.
What we need
- Access to the people who hold the context — product, and whoever knows the current system.
- Whatever exists today: diagrams, code, docs, or just an honest description if there's nothing written.
- The real constraints — budget, timeline, launch markets and any non-negotiables.
What it doesn't include
- Writing production code — that begins after sign-off, if you choose to build with us.
- A fixed quote for the full build — the roadmap is what makes a real estimate possible.
- Vendor lock-in — the artifacts are yours to take anywhere.
Every engagement starts here.
Before the first line of code, there's the architecture review. That's where we find out whether your idea is ready — and exactly what it needs to last.
Book the Architecture Review