An independent read on the design you are about to commit to.
Two to three weeks, written down, and independent of whoever built it — including us. You get findings ordered by risk and by cost of delay, the reasoning behind each, and an explicit list of what does not need to change.
The design review that happens inside the team that made the design.
Architecture decisions are made under deadline, by people with a legitimate stake in the answer, and then become expensive to revisit. Six months later nobody wants to be the one to reopen them. An outside read is cheap at the point where the decision is still reversible and very expensive afterwards.
Diagrams that no longer match
The architecture document describes an intention. The running system has three years of pragmatic decisions in it that nobody recorded.
Scale assumed, never modelled
A design chosen for a load nobody has calculated, and a cost curve nobody has drawn past the pilot.
Findings with no priority
A review that produces sixty observations of equal weight is a document that gets filed. The value is in knowing which three matter.
Eight dimensions, weighted by what your system actually faces.
Boundaries & coupling
Where the seams are, whether they follow the domain or the org chart, and which changes currently require touching four services and three teams.
Scale & performance
The load model, the bottleneck you will hit first, and whether the growth assumption in the plan is arithmetic or optimism.
Resilience & failure
What happens when each dependency fails, whether the recovery objectives have ever been tested, and where a single failure takes more than it should.
Security & data
Trust boundaries, identity, secrets, data classification and residency, and the exposure that would be reported if it went wrong.
Standards & ISOCost & operability
What it costs to run at real volume, what it costs to operate in people, and whether the on-call burden is sustainable for the team you actually have.
Change & delivery
How long a change takes from decision to production, how much of that is waiting, and what the architecture is doing to cause it.
AI and data readiness
Whether the design can support the AI or analytical work that is on the roadmap, or would have to be reopened to do it.
AI readinessTeam fit
Whether the architecture matches the size, skills and geography of the team that has to run it. Elegant designs fail on this more often than on any technical dimension.
Two to three weeks, and light on your team's time.
Read
Code, infrastructure definitions, diagrams, incident history and the last few post-mortems. We read the system before we ask anyone about it.
Ask
Interviews with the architect, the engineers, whoever is on call and whoever carries the commercial risk. The four accounts rarely agree, and the disagreement is informative.
Model
Load, failure and cost modelled against what the business expects, so the findings rest on numbers rather than taste.
Report
Written findings ordered by risk and cost of delay, each with evidence, an option set and a recommendation, plus a session with your team and one with your leadership.
Including when the answer is that it is fine.
A review that finds a crisis every time is a sales instrument, not an assessment. We state plainly what is working and should be left alone, we separate genuine risk from stylistic preference, and where a finding is a matter of taste we label it as one. If the design is sound, the report says so and you have spent two weeks buying confidence.
Advisory programme
When the question is broader than architecture: process, people, delivery and vision drift over four to six weeks.
The advisory programmeSoftware architecture
When you want the design built or reworked rather than assessed.
Software architectureProduct & investment evaluation
Technical due diligence when money is about to move.
Due diligenceQuestions we get asked
Will you review a system you built?▼
We will, but we will tell you plainly that it is not independent, and for anything carrying real risk we would rather you had someone else do it. Independence is the whole product here.
How much access do you need?▼
Read access to the code and infrastructure definitions, whatever documentation exists, incident history, and about six to ten hours of interview time spread across the team. We do not need write access to anything.
What if the review says we should stop what we are building?▼
Then it says that, with the reasoning and the alternatives, and we will present it to whoever needs to hear it. It is an uncomfortable report to receive and a considerably cheaper one than the alternative.
Can you review a design before it is built?▼
Yes, and that is the cheapest point to do it. For a design still on paper the review is usually shorter — one to two weeks — and focuses on the assumptions, the load model and the decisions that would be expensive to reverse.
Do you provide a remediation plan?▼
The report includes an option set and a recommendation per finding, with rough effort. A detailed remediation plan is a separate piece of work, and you are free to have anyone do it, including your own team.
One free hour. No pitch, no obligation.
Bring the problem you are stuck on — an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.
- Architecture and integration review
- AI feasibility — what will actually work, and what will not
- AWS, Azure and Google Cloud cost and design
- Business process audit and ISO readiness
- Technical due diligence before you invest or acquire