Technical Architecture Review SOP

A technical architecture review SOP puts two or three experienced engineers in front of the shape of your system before months of code set it in stone, and the whole cycle takes about two weeks. You draw the system, write down the handful of things it must do well, and ask reviewers to break it on paper. Moving a box on a diagram costs an afternoon. Moving it after launch costs a rewrite. You walk away with a ranked list of risks, the decisions you can still reverse cheaply and a written record of the ones you can't.

What is the technical architecture review SOP and when should you use it?

An architecture review is a structured walk-through of how your components, data stores and third-party services fit together, judged against the quality attributes your business needs: security, reliability, speed, cost and how easy the system is to change. The method in this SOP is a startup-sized version of ATAM, the Architecture Tradeoff Analysis Method from the Software Engineering Institute at Carnegie Mellon University, which you can read about in the SEI ATAM collection.

The technology stack validation SOP picks the tools. The technical feasibility assessment asks whether the thing can be built at all. This review asks whether the pieces, as you arranged them, hold up when something goes wrong.

Use it:

• Before a developer or agency starts building from your spec, while changes are still cheap.
• When a fast prototype becomes the real product. No-code builds and AI-generated code tend to skip structure, and a review catches that early.
• Before a hard-to-reverse choice, such as how you separate customer data or which vendor holds your files.

What do you need before you start?

• Two diagrams in the C4 model by Simon Brown: a System Context diagram (your product, its users, outside systems) and a Container diagram (web app, API, database, queue, third-party services). The C4 model site shows both levels.
• 5 to 8 quality scenarios, each with a trigger, a response and a measurable target.
• Your decisions so far, written as Architecture Decision Records (ADRs) in Michael Nygard's format: context, decision, status, consequences.
• 2 or 3 reviewers, at least one who has run a live system for paying customers.
• A findings log, ready before the meeting.

How do you run it, step by step?

1. Draw the system at two zoom levels

Make one Context diagram and one Container diagram, each on a single page. Label every arrow with what flows and how: "HTTPS/JSON", "webhook", "nightly CSV export". If you can't draw it, nobody can review it.

2. Write the quality scenarios your business depends on

Pick characteristics from the ISO/IEC 25010 quality model, such as security, reliability, maintainability and compatibility, and turn each into a scenario: "When 500 customers upload invoices in the last hour of the month, every upload finishes in under 10 seconds." Rank them by business damage. A health app ranks data confidentiality first; a ticketing site ranks the Friday-evening traffic spike first.

3. Mark one-way and two-way decisions

Jeff Bezos's shareholder letters split decisions into Type 1 (one-way doors, hard to reverse) and Type 2 (two-way doors). Label each ADR. The database engine and the way you separate customer data are one-way doors; the CSS framework is a two-way door. Spend most of the review time on the one-way doors.

4. Send the pack three days ahead

Send diagrams, scenarios, ADRs and the three questions that worry you most. Ask each reviewer to write their top risks alone before the meeting.

5. Walk each scenario through the diagram

For each scenario, the person who knows the system traces a request through the boxes: which part handles it, where data lands, who can read it and what happens when that part fails. Reviewers log every finding with ATAM's labels: risk, non-risk, sensitivity point or tradeoff point. Give each scenario 20 to 25 minutes.

6. Rate, rank and assign

Score each finding for likelihood (1 to 3) and damage (1 to 3) and multiply. A score of 6 or 9 counts as high. Every high finding gets an owner, a fix or a written acceptance, and a date.

7. Record the outcome and book a re-check

Write an ADR for every change and every accepted risk. Book a one-hour re-check after 30 days, or earlier if you face a new one-way decision.

Template you can copy

ARCHITECTURE REVIEW PACK

1. Context diagram (C4 level 1)            [link]
2. Container diagram (C4 level 2)          [link]
3. Quality scenarios (ranked)
   # | Trigger | Expected response | Target | Business damage if missed (1-3)
   1 |         |                   |        |
4. Decisions so far (ADRs)
   ADR# | Decision | One-way / two-way | Status | Consequences
5. Three questions that worry us most
   a)
   b)
   c)

FINDINGS LOG
ID | Scenario # | Component | Finding | Type (risk / non-risk /
sensitivity / tradeoff) | Likelihood 1-3 | Damage 1-3 | Score |
Owner | Fix or accepted (ADR#) | Due date | Status

DECISION SUMMARY (one page)
- High risks found: __   Fixed: __   Accepted with ADR: __
- Single points of failure: __ (each with a recovery plan Y/N)
- Next re-check date: __

Worked example: an invoice-scanning tool for small agencies

This is an illustrative case. Two founders have a contractor-built prototype: one server runs the web app, the text-recognition jobs and a PostgreSQL database. Uploaded files sit on the server's own disk, and each upload calls an outside OCR service while the customer waits.

They write six scenarios and invite two reviewers, one of them a former engineering lead at a payments company. The walk-through produces 14 findings, four of them high:

• At month end, 500 uploads in an hour would hold open 500 waiting web requests, and any OCR call over 30 seconds times out.
• Files live on one disk with no copy, so a dead server means lost invoices.
• Three tables have no customer ID column, so one bad query can show Agency A's invoices to Agency B.
• Backups run nightly, and nobody has ever restored one.

The fixes: a job queue for OCR, object storage for files, a customer ID plus row-level security in PostgreSQL, and a monthly restore drill. The contractor estimates 9 developer days. The same changes after launch, with live customer data to migrate, would take an estimated 6 to 8 weeks.

What should you measure, and when do you stop?

Stop when a second walk-through of the top scenarios turns up no new high risks. Log the medium findings and revisit them at the 30-day check.

Which mistakes should you avoid?

• Reviewing code instead of structure. Line-by-line comments belong in pull requests.
• Letting the builder be the only reviewer. The contractor who built the prototype will defend it. Bring at least one outside pair of eyes.
• Designing for a billion users. A fleet of microservices for 50 customers is a cost you pay every week.
• Skipping the failure question. "What happens when this box dies?" is the most useful sentence in the whole review.
• Keeping decisions in your head. Without ADRs, the next developer reopens every settled debate.

How can AI speed this up?

Write your Container diagram as text (Structurizr DSL or Mermaid) and paste it into an AI assistant with your scenarios. Ask it to list failure modes per component, missing arrows and single points of failure, then to draft an ADR for each decision you describe.

The human check still matters: AI knows nothing about your contract terms, your team's skills or your budget, and it tends to recommend heavier designs than a startup needs. Treat its list as homework for reviewers. If you want a sparring partner for this kind of structured thinking, the F/MS AI co-founder works through technical and business decisions step by step.

Where does this SOP fit in your validation plan?

The review sits in the middle of the Technical Validation SOPs:

1. Before it: confirm the idea can be built with the technical feasibility assessment and a proof of concept.
2. After it: test the risky parts it flagged with the security validation SOP, the technical scalability assessment and the data architecture validation SOP.
3. Keep your launch prep in one place with the free startup checklist creator, so the fixes from the review get a slot before go-live.

FAQ

Who should review my startup's architecture if I am not technical?

Ask two people: one engineer who has run a live product with paying customers, and one who knows your domain (payments, health, education). Pay a fractional CTO for half a day if your network has no one; that is cheaper than a rewrite.

How is an architecture review different from a code review?

A code review checks individual changes for bugs and style. An architecture review checks how the whole system behaves under load, failure and attack, using diagrams and scenarios instead of code.

How long does a startup architecture review take?

Plan 3 to 5 days to prepare the pack, a half-day session and about a week to fix high-risk findings.

When should we repeat the architecture review?

Re-check 30 days after the first review, then before each new one-way decision: a new database, a new region, a big customer with special data rules, or a move from prototype to paid product.