Architecture & Technical Review

Most systems do not need replacing. Some do.

Reading a system you already own and reporting what it will and will not support — because "replace it" is an expensive default when the actual bottleneck is one subsystem.

Why this comes up

The request usually arrives with the conclusion already attached: the system is old, everything takes too long, we think we need to rebuild. Sometimes that is right. More often the frustration is real and the diagnosis is wrong — the slowness is one subsystem, or a deployment process, or the fact that nobody has been allowed to delete anything in four years.

The cost of getting this wrong is asymmetric. A rebuild is eighteen months during which the business gets no new capability, and it is very often funded on a feeling rather than on evidence. Meanwhile the actual constraint — a schema that cannot express a product the company now sells, or a single integration that fails silently — goes unnamed and survives into the replacement.

So this engagement produces a document, not code. What the system will support, what it will not, what it would cost to change that, and which of those is worth doing. Written to be read by whoever holds the budget, because a finding only an engineer can evaluate does not help the person who has to decide.

What you get

Deliverables, not adjectives

A prioritised findings report

Each finding with its evidence, its business consequence and its rough cost to address, ordered by what actually matters. Explicitly separating what is dangerous from what is merely unfashionable — those get conflated constantly, and the conflation is expensive.

A straight answer on rebuild versus repair

Including the option people avoid proposing: keep the system, fix two things, revisit in a year. If a rebuild genuinely is the right call, you get the case for it in a form you can take to a board — and if it is not, you get that in writing too.

Scoping that produces a cut list

A working session that turns a wish list into a sequence: what is in, what is deferred, what is out, and what each cut costs. You leave with a written scope rather than a proposal deck, and it is yours whether or not we build anything.

Handover and maintenance planning

For systems changing hands: what has to be documented, what only exists in one person's head, what the maintenance actually costs per year, and what breaks first if nobody touches it. Frequently the most valuable part, and the least requested.

Scope at a glance

Codebase and architecture audits with prioritised findings
Scoping sessions that produce a cut list, not a wish list
Build-versus-buy and replatforming assessments
Handover, documentation and maintenance planning

What we reach for

Defaults rather than rules. Each one gets argued against on a project where it does not fit — the reasoning matters more than the tool.

What we read: The codebase, the schema, the deploy pipeline, the incident history and the backlog.
Who we talk to: The engineers who maintain it and the people who use it daily — separately, because the accounts differ.
What we measure: Change lead time, failure rate and the real cost of the parts everyone avoids touching.
What you get: A written report and a working session on it. Not a slide deck presented once and lost.

How it runs

Durations are ranges because a single confident number this early is a guess in a suit.

Engagement shape

Fixed scope and fixed price. It ends with a document, and it can end there.

Typical duration

Two to five weeks depending on the size of the estate.

Starts with

Read access to the repository and an hour with whoever knows the most history.

When this is the wrong thing to buy

We would rather lose the enquiry here than three months in. If you recognise your situation below, say so on the first call and we will tell you what we would do instead.

Producing a report that supports a decision already made. If the evidence points the other way, that is what the document will say.
Reviewing a system we would then be the only plausible bidder to rebuild. If that conflict exists, we will name it before you engage us.
A one-hour opinion on an architecture diagram. Diagrams describe the intended system; the findings that matter come from the one that exists.

Questions we get asked

Will you recommend rebuilding so you win the rebuild?

That conflict is real and worth naming out loud. Two things address it: the review is fixed price and complete in itself, so it does not depend on further work, and the report states what keeping the system would cost alongside what replacing it would. Roughly half of these engagements end with us recommending against a rebuild.

Do you need access to our production systems?

Read access to the repository is the essential part. Production telemetry helps and can be shared in whatever redacted form your policies allow. We do not need write access anywhere.

Can you review work another vendor built?

Yes, and it is a common reason for the call. We report on the system rather than on the vendor — findings are about what the code does and what it will cost you, not about assigning blame for how it got there.

What if we just need help deciding whether to build or buy?

That is a shorter version of the same engagement. We look at what the off-the-shelf options genuinely cover, where your process actually differs from the standard one, and what the integration and configuration cost of buying really is — which is the number that is usually missing from the comparison.

Talk to us about architecture & technical review

Send the problem rather than a feature list. You will get an approach, a range and an honest view of what it takes — including whether you need this at all.

Book a 15-min strategy call