For decisions too expensive to make on instinct
Software Architecture
The expensive architectural mistakes are rarely wrong technology choices. They are undocumented assumptions that nobody stress-tested before the build started. This practice makes the trade-offs explicit, whether you are reviewing a plan before it costs money, diagnosing why a system stopped scaling, or assessing technical risk before a deal closes.
How an architecture review actually runs
From assumptions to a written decision record your team can build from.
90 secSample frame · video pending01Before commissioning a review
Not every architecture question needs a formal review.
A review earns its cost when the decision is expensive to reverse. Four tests decide whether that threshold is met.
Would a wrong decision cost six figures to reverse?
If the choice is cheap to change later, a formal review is overhead. Reviews earn their fee on decisions that are hard to walk back.
Does the team already disagree?
An independent review resolves internal disagreement with evidence rather than seniority, which is often the actual value being purchased.
Is this decision about to be made under deadline pressure?
Rushed architecture decisions are where the expensive mistakes concentrate. A short review before the pressure peaks is cheap insurance.
Does an external party need to trust the answer?
Investors, acquirers and boards often need independent validation that internal engineering cannot itself provide credibly.
| Internal decision | Independent review | |
|---|---|---|
| Speed | Faster | Adds structured time |
| Bias | Reflects existing team incentives | Independent of internal politics |
| External credibility | Limited | Carries weight with boards, investors |
| Right for | Low-stakes, reversible choices | Expensive, hard-to-reverse decisions |
02Agreed before the review starts
The ledger that keeps the engagement honest
Architecture engagements go wrong when the reviewer starts making decisions that belong to the client. This ledger keeps the split explicit: what you bring, what we assess, what returns, and what stays yours.
- Your side
You bring
- The proposed architecture and its assumptions
- Expected load, growth and compliance duties
- The team that will build and maintain it
- Our side
We build
- A structured review of the proposed design
- Trade-offs made explicit with their consequences
- Alternative approaches costed where they exist
- Your side
You receive
- A written architecture decision record
- Identified risks ranked by likely cost
- A defensible plan your engineers can build from
Never leaves you
- The final decision on which path to take
- Ownership of every architectural trade-off made
- The build itself and its timeline
Where the line sitsWe review and recommend. The decision, and the consequences of it, stay with your team, documented well enough to survive the people who made it leaving.
03From assumptions to a defensible plan
Four stages, each closing on evidence
A review that produces only opinions has failed. This system closes every stage with something written down that your team can act on or challenge.
Surface what is currently assumed
Load estimates, growth projections and constraints are stated plainly, because most architecture arguments are actually disagreements about unstated assumptions.
Assumptions made explicitModel the real trade-offs
Each significant choice is costed against its alternatives in terms your board and your engineers can both evaluate.
Trade-offs with real numbersRank findings by consequence
Findings are ordered by cost of inaction, not by novelty or engineering interest, so attention goes where it changes outcomes.
A ranked risk registerWrite the decision record
The output is written to be understood by whoever inherits the system in two years, not just by the people in the room today.
A record built to survive
04What actually moves the number
Four drivers, priced from the scope
Architecture work is priced against the assessment, because these four factors change the effort by multiples.
System size and complexity
A single service review costs less than a full-estate assessment spanning dozens of interconnected systems.
Documentation quality already available
Well-documented systems review faster. Undocumented systems require reconstructing the architecture from the code itself first.
Stakeholder alignment required
A review feeding one technical decision costs less than one that must satisfy engineering, finance and an external board simultaneously.
Confidentiality and access constraints
Due diligence reviews often work under restricted access and tight timelines, which shapes the engagement differently from an internal review.
05Evidence and proof
Decisions that held up under real scrutiny.
Architecture proof is a decision record still in use months later. Every record here waits for written client approval before production.
Explore case studiesA review that changed the plan before a seven-figure build started.
A platform team was weeks from committing to a build. An architecture review found a service boundary flaw that would have cost a quarter to fix post-launch.
- Rework avoided
- Estimated one quarter
- Review duration
- Two weeks
A scaling diagnosis that avoided a full platform rewrite.
Vela Ledger's platform was straining under growth. The diagnosis found the actual bottleneck was two services, not the whole architecture, saving a costly rewrite.
- Systems requiring change
- 2 of 14 services
- Rewrite avoided
- Full platform
The report was written so our board could read it too, not just our engineers. That mattered more than we expected going in.
Sample · pending client approval
06Read this first
When a formal review is the wrong spend
Commissioning a full review for a decision your team can safely reverse wastes money better spent building. The exits are marked plainly. Where architecture work is justified, findings apply across cloud, service and data architectures on the stacks your teams already run.
The decision is genuinely low-stakes
If reversing the choice later costs little, build and learn instead of paying for a formal review of something reversible.
- Custom software development
You need the system built, not just reviewed
If the architecture question is settled and the need is execution, a scoped build gets you there faster than another review.
- Team extension
You need an architect on staff, not a report
If ongoing architectural leadership is the actual gap, team extension puts a senior engineer inside your process instead.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Focused review | One decision needs validation | What happens with the findings | The assessment and the record |
| Estate assessment | Multiple systems need mapping | Priorities across findings | The full review and roadmap |
| Embedded architect | Ongoing decisions need a senior voice | Product and technical direction | Architectural leadership inside your team |
07Straight answers
Asked before an architecture decision is made.
01Do you only review, or do you also build?
Both, depending on what you need. Many clients commission a review specifically because they want an independent assessment before committing to a build, which may or may not be with us.
02How long does an architecture review take?
A focused review of one decision typically takes one to two weeks. A full estate assessment spanning multiple systems takes longer, scoped against the system count and documentation quality at hand.
03Can you review architecture for an acquisition?
Yes, technical due diligence for acquisitions and investments is a distinct exercise from an internal review. It serves the party commissioning it, and the report is written for a commercial as well as a technical audience.
04What is technical due diligence and how is it different from a build-side review?
Technical due diligence assesses risk for a buyer or investor deciding whether to proceed with a deal. A build-side review helps an owner decide what to build next. The examination overlaps; the audience and the questions differ.
05What does an architecture review cost?
Priced against system size, documentation quality and stakeholder requirements from the scoping conversation. A focused single-decision review costs less than a multi-system estate assessment.
06Will you tell us what we want to hear?
No, and that is the actual value of an independent review. Findings are reported plainly, including when they contradict the direction leadership was already leaning toward.
07Do you help implement the recommendations afterwards?
Where useful, yes, though the review itself is independent of that decision. Many clients take the decision record to their own team or another vendor, which the document is written to support either way.