The Architecture Review Checklist
The five-stage checklist we run before committing build budget — published in full. Use it to pressure-test a system on paper while changes are still cheap, whoever you build with.
One question, answered before it's expensive
An architecture review answers a single question: will this system survive contact with real load, real markets and real change — before it is expensive to find out? The checklist below is the same sequence we run on every engagement, described in full on our architecture review page.
Five stages, every box checked
Each stage produces something concrete. If a stage produces nothing written, it didn't happen.
Discovery
- Product goals written down and agreed
- Hard constraints listed — budget, deadline, compliance, team
- Launch markets named, including data-residency implications
- Decisions already made (and unchangeable) identified
Output: a shared, written problem statement
System mapping
- Current or intended system drawn end to end
- Every request path traced, client to response
- All third-party dependencies mapped
- The location of every piece of state made explicit
Output: a system diagram that matches reality
Risk & load review
- System modelled at 10x launch-day load
- Single points of failure named
- Blocking work in the request path identified — email, exports, PDF generation
- Data-residency gaps checked against launch markets
- Hot tables and unindexed queries flagged
Output: a ranked risk register
Trade-off decisions
- Each major call recorded as an ADR — context, options, choice, and what it costs later
- No decision left implicit
- Reversible and hard-to-reverse decisions separated
Output: a decision log (ADRs)
Sign-off & handoff
- Full walkthrough with the owning team
- All artifacts handed over — the client owns them, build or not
Output: a signed-off architecture you keep
Want us to run this checklist against your architecture?
A free 30–45 minute Risk Review with a senior engineer: your top three architectural risks, ranked, plus a one-page written summary. No deck, no pitch.
Request Architecture Risk ReviewSix artifacts every review must produce
However you run the review — with us, in-house, or with another firm — insist on all six. A review that produces fewer is a conversation, not a review.
Architecture diagram
What the system actually is — request paths, data flows, third parties and where state lives.
Risk register
What breaks first and how badly — ranked by likelihood and blast radius, each with a mitigation.
Decision log (ADRs)
Why each call was made — context, options considered, and the cost accepted.
Scalability model
What 10x load does to the system, where it bends first, and the order to reinforce it.
Cost-to-scale view
What growth costs in infrastructure and rework — so scale isn't a financial surprise.
Phased roadmap
What to build first, what can wait, and the sequence that keeps you shippable throughout.
The one-minute ADR template
Stage 4 runs on this. Copy it into your docs and record every hard-to-reverse call — the format matters less than the habit.
# ADR-001 — [short title of the decision]
Status: proposed | accepted | superseded by ADR-xxx
Context: What forces are at play? What constraint or growth
assumption makes this decision necessary now?
Options: The 2–3 realistic alternatives, one line each —
including "do nothing."
Decision: What we chose, stated in one sentence.
Consequences: What this costs us later. What becomes easier,
what becomes harder, and when to revisit.
The failure modes that keep showing up
Patterns we find over and over in systems that felt fine at launch. If your checklist run surfaces any of these, they belong at the top of the risk register.
In the request path
- Blocking I/O inside requests — p95 latency explodes the moment traffic spikes.
- No queue, no background workers — exports, email and PDF generation built inline.
- A single database node with unindexed hot tables.
In the structure
- State scattered across services with no single owner.
- Compliance — like EU data residency — discovered after market entry, not before.
- Hard-to-reverse decisions made implicitly, with no record of the alternatives.
The checklist finds the questions. The review answers them.
Run it yourself — it's yours. And when you want senior eyes on the answers, that's the work we do at HiQByte.