Architecture Review
An outside read on the system you already have. What it will survive, what it won’t, and what to fix first.
Most teams don’t need telling that their architecture has problems. They know. What they usually can’t do is separate the problems that will hurt them next quarter from the ones they can live with for another two years, and put that in writing in a form both the engineering team and the people paying for it will accept.
So that’s what I do. Two to four weeks inside your codebase, your infrastructure definitions and your incident history, and you get back a prioritised account of where the architecture stands and what it will cost you to leave it there.
I lead architecture for a multi-region platform serving customers across Asia and Europe, with engineering teams in Taiwan, Israel and Australia. The reason that matters here: the recommendations come with production scars attached. They have been paid for in incidents, on-calls and cross-border launches, not sketched on a whiteboard.
What you get
A written risk register
Every architectural risk I find, stated plainly, with the conditions under which it turns into an incident and an honest read on how likely that is. Not a severity colour chart. A document your engineers can argue with.
A prioritised remediation roadmap
What to fix, in what order, and roughly what each fix costs in engineering time. Ordered by risk retired per unit of effort, so it survives contact with a real backlog and a real deadline.
An executive readout
The same findings in the language your overseas HQ uses. This is usually the part that unblocks budget. A technical report that never leaves the engineering org tends not to change anything.
How it works
-
01
Discovery call
A short call to work out what is really being asked. Sometimes the presenting problem is not the question worth answering, and it is cheaper for both of us to find that out on a call than in week three.
-
02
Scoped proposal
Fixed scope against defined deliverables, not an hourly meter. You know what you are buying before the work starts.
-
03
Reading the system
Code, infrastructure definitions, data models, deployment topology, and the incident history. That last one is usually the most informative artefact in the building. Where a system has broken tells you more than a diagram of where it was meant to hold.
-
04
Deep dives with your engineers
A few focused sessions on specific subsystems. Your team knows where the bodies are buried, and asking them is faster and more accurate than guessing.
-
05
Readout and handover
Findings presented to the engineering team, and separately to whoever funds the work. The written artefacts are yours to keep and reuse.
When a review earns its cost
The engagements that pay for themselves usually start from one of these:
- A scaling step is coming and nobody can say for certain whether the current design absorbs it.
- Incidents are getting more frequent and the causes look structural rather than one-off.
- Someone has proposed a rewrite or a replatform, and the argument needs testing before it gets funded.
- Overseas HQ has been asked to approve serious engineering spend and wants an outside read first.
- Delivery has slowed and nobody can point at why. Coupling is the usual suspect.
- A key architect left, and the decisions they made now live only in the code.
What I won’t do
A review is an assessment, not an implementation. My focus is architectural decisions, system design and engineering judgement; your team writes the code. Where it helps, I will write a reference implementation to prove out a critical path, but I am not a contractor delivering production software.
I also don’t do compliance audits, penetration tests or code-quality scans. Those are separate disciplines with their own tooling, and a review that claimed to cover all three would be doing each of them badly.
Who this is for
Companies with 30 to 500 engineers globally, usually with a regional office or engineering hub in Taiwan. Three patterns come up again and again: foreign-owned subsidiaries in Taipei, Taiwan-headquartered SaaS companies scaling internationally, and US or European companies running engineering teams in Asia.
What they have in common is a translation problem sitting on top of a technical one. A capable local engineering team, and a headquarters that needs to understand and fund its decisions from eight time zones away.
Common questions
How long does an architecture review take?
Typically two to four weeks of calendar time, depending on system complexity and the number of stakeholders. The deliverable is a written risk register, a prioritised remediation roadmap, and an executive readout.
How much of my team’s time does it take up?
Less than most teams expect. Most of the work is me reading your code, your infrastructure definitions and your incident history on my own time. I’ll need a kickoff session, a few ninety-minute deep dives on specific subsystems, and a slot for the readout. Your sprint doesn’t stop.
Will you tell us to rewrite everything?
Almost certainly not, and I’d be suspicious of anyone who did. A rewrite swaps a system whose failure modes you know for one whose failure modes you don’t. Most of what I find is narrower: a boundary in the wrong place, a data model that blocks the next scaling step, a coupling that turns a small change into a release-wide risk.
Our engineers built this. Won’t a review turn political?
It can, and avoiding that is a real part of the job. I assess decisions against the constraints that existed when they were made, not against hindsight. If your engineers read the report and get defensive, I’ve written it badly, whatever it found.
Do you work remote, or only on-site in Taipei?
Both. Most engagements are hybrid, with discovery and key workshops in person in Taipei where that’s practical and the rest delivered remotely. Fully remote engagements are also available.
Can you work with a Mandarin-speaking engineering team?
My working language is English. I don’t speak or write Mandarin, so engagements with a Mandarin-only team need an English-speaking bridge, usually a bilingual team lead or engineer on the client side, or a paid interpreter for key sessions. Most foreign-owned subsidiaries in Taipei already run in English internally, so for that shape of engagement it isn’t a blocker.
Related services
Start a review
Engagements are quoted as fixed scope against defined deliverables, after a short discovery call. I take on one or two new consulting engagements per quarter alongside my ongoing work, so lead times vary. Worth asking early.
Get in touch, or read more about my background.