Focused second opinion
Architecture Peer Review
An independent senior opinion before you commit.
A senior architect checks one software or AI architecture decision: a design, a vendor proposal, a platform or integration choice, or a technical direction your team disagrees on. You get the risks that matter, the alternatives, and what must be true before you go ahead.
What you receive
A short report on one decision.
It starts with one of four answers: Go ahead · Go ahead, with conditions · Not yet (not ready, or not enough evidence) · Stop. It is our recommendation, not a certificate or a guarantee.
- The findings that matter, our assumptions, the alternatives, the trade-offs and the conditions for proceeding.
- How we know each finding: Verified (we saw it in the code, configuration or running system), Inferred (it follows from what we saw), Reported by your team (what people told us, not yet checked) or Still open (we couldn't settle it). What we didn't examine is listed separately.
- A walkthrough with the people making the decision, and clear next steps.
The engagement
One decision. A defined review.
- Scope
- One proposed or existing software or AI architecture decision, its alternatives and the assumptions behind it. We agree the question and the evidence boundary before work starts.
- Inputs
- Access to the design, proposal or system, your constraints, and a few hours with the people who know the background.
- Deliverables
- The report and a walkthrough with the people making the decision. The answer covers the question we agreed and the evidence we saw.
- Fee
- A fixed fee, agreed before work starts.
When this helps
Recognise the situation.
- An AI platform, agent design or AI vendor proposal needs its data access, evaluation and failure handling tested before you approve it.
- You are about to approve a design, a vendor proposal or a significant technical direction.
- Your team needs a senior second opinion on a software or AI design choice, or disagrees on one.
- You are choosing a platform or an integration approach.
How it works
Evidence appropriate to the question.
Agree the question
We agree the decision, the constraints and the assumptions that matter.
Test the design
We review the evidence, look for failure modes and trade-offs, and test the reasoning with the people who own it.
Walk you through the report
We present the strengths, the risks, what the design leaves out and the conditions for proceeding.
Scope & responsibility
Agree the scope and depth. Keep the boundaries clear.
Scope of the engagement
One decision, not a check of the whole system. A design review can work from documents. A question about a live system may need some code or operating data. For wider or design-stage questions, the deeper step is an Architecture Diagnostic; for a working product before its next stage, it is a Production Readiness Assessment.
Limits of reliance
The answer covers the question we agreed and what we saw. It is not a security test or a compliance review. We aren't tied to any software vendor.
The agreed scope of the engagement sets the coverage, deliverables, responsibilities, timing and fixed fee. Any change to the scope is agreed in writing.
We tell you if we worked on this system before, and we agree up front who hires us and how the report may be described to others.
Questions
Before you book.
How is this different from the Diagnostic or Production Readiness?
Peer Review answers one architecture question. The Architecture Diagnostic is the deeper step for wider or design-stage questions: it investigates the wider system or design, its interacting risks and the direction needed. Production Readiness looks at a whole working product before its next stage, at the depth you choose.
Can you review another firm's design?
Yes, within an agreed scope and access. The review covers the design and the decision, not the other firm. The report says who asked for it, who paid and who can rely on it.
What happens to our documents and code, and where do they go?
We use a set of tools that can run outside or inside your environment, depending on the case. We agree which, and sign an NDA, before we see any code. See Trust & information handling.
How are fees set?
A fixed fee for the agreed question, set before work starts. We discuss the amount on the call.
How long does it take?
It depends on the decision and the size of the system. One decision on a small system usually takes about a week. A large system can take two to three weeks or more. We agree the timing and a fixed fee before work starts.
Related work
Related services
Each is available as a standalone service when the evidence and scope support it.
What's the decision in front of you?
Tell us the situation and what you intend to commit to. 25 minutes on Teams, no preparation needed. If this scope is not the right fit, we will say so.