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.
In short: the fix moved every piece of blocking work out of the request path, split reads from writes with replicas and a cache, and isolated regions for data residency — all without breaking the system into microservices.
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.
What a deliverable actually looks like
Not a polished graphic — a working entry from the risk register, the way your team would receive it.
[RISK-04] severity: CRITICAL blast: HIGH
component month-end export worker
failure memory exhaustion under bulk
multi-tenant export load
mitigation move exports off the request path:
queue + chunked upload to object store;
cap per-tenant concurrency
status accepted · scheduled · roadmap stage 1One of dozens of entries. Every risk we find is logged like this — ranked, traced to a component, and tied to a fix.
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 expensive mistakes, caught on paper
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.
rewrites forced by a wrong foundation — the failure modes are found and priced before code, while they're still cheap to fix.
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.
Find your top three risks — before you commit the budget
Before you commit months of engineering effort, we'll identify the three architectural decisions most likely to create avoidable cost, delay or rework — in a 30–45 minute working session with a senior engineer, followed by a one-page written summary. There is no charge.
What you walk away with
- Your top three architectural risks, ranked — scalability, cost, or compliance — with the reasoning behind each.
- One concrete recommendation you can act on immediately, whoever you build with.
- A one-page written summary within two working days of the call.
What it isn't
- A full architecture review — this is the 30-minute version of the two-to-three-week process above.
- Free ongoing consulting — one session, one summary, and a clear next step if you want to go deeper.
- A sales presentation. This is a working session — and if the honest answer is "you don't need us yet," that's what the summary will say.
Request a Risk Review
To keep the session useful, we ask what we can review — an architecture diagram, a product spec, or a repository. No formal artifact yet? Run through the checklist first, then tell us what exists today — a Notion doc or a plain description works. Required fields are marked *
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.