Clear technical decisions before expensive commitments.
Independent architecture reviews, technical second opinions, and due diligence for software decisions that are costly or difficult to reverse.
- Question
- Should the platform be rewritten before the next growth phase?
- Evidence
-
- Core domain behaviour remains stable
- Operational failures are concentrated in two boundaries
- Most delivery delays come from integration and deployment constraints
- Recommendation
- Incremental replacement
- Not recommended
Full rewrite
- Preserves releasability
- Targets the actual constraints
- Reduces delivery and migration risk
- Allows evidence to guide later stages
When the decision matters more than the technology.
The most expensive technical mistakes are often made before implementation begins. ClarusTech helps make the constraints, alternatives, and consequences explicit.
-
A vendor proposal is difficult to evaluate.
The scope is large, the terminology is persuasive, and the long-term technical and commercial consequences are unclear.
-
A rewrite is being considered.
The existing system is difficult, but it is not yet clear whether replacement addresses the real constraint.
-
Several architecture options appear defensible.
Leadership needs a recommendation grounded in business needs, operational capability, cost, and reversibility.
-
A build-versus-buy decision is approaching.
The organization needs to understand ownership, integration, licensing, dependency, and exit costs before committing.
-
An investment or acquisition needs technical scrutiny.
The system, team, architecture, risks, and modernization needs must be understood before the transaction proceeds.
-
A critical decision needs an independent second opinion.
Internal teams and vendors have legitimate interests in the outcome. Leadership needs a view without delivery pressure.
Three kinds of independent review.
Architecture Review
Independent assessment of an existing or proposed software architecture.
- System boundaries and coupling
- Quality attributes and constraints
- Data and integration architecture
- Deployment and operational model
- Security and dependency exposure
- Changeability and migration risk
Understand what is sound, what is risky, and what should change first.
Technical Decision Review
Focused analysis of one consequential technical choice.
- Build versus buy
- Platform and vendor selection
- Rewrite versus incremental modernization
- Cloud and infrastructure direction
- Framework or architecture selection
- AI feasibility and operating model
Make a defensible decision with explicit trade-offs.
Full scopeTechnical Due Diligence
Independent review for investment, acquisition, partnership, or major commercial commitment.
- Architecture and codebase condition
- Delivery capability
- Scalability and reliability
- Security and operational exposure
- Technical debt and modernization needs
- Key-person, vendor, and dependency risk
Understand the technical asset, liabilities, and likely investment required.
Advice should not depend on selling the implementation.
Implementation vendors are often best placed to describe how they would deliver a solution. They are not always best placed to determine whether the solution should be purchased, built, migrated, or replaced at all.
- Separate the recommendation from the delivery opportunity
- Document rejected alternatives and their costs
- Distinguish business constraints from technology preferences
- State uncertainty and missing evidence explicitly
- Evaluate reversibility before committing
- Recommend no change when no change is justified
Independent technical decision review.
A focused engagement for organizations facing a consequential software, architecture, vendor, migration, or investment decision.
What we examine
- Business objective and decision context
- Current system, operating constraints, and organizational capability
- Realistic alternatives and their trade-offs
- Delivery, ownership, and lifecycle costs
- Security, supply-chain, and dependency exposure
- Evidence quality and unresolved assumptions
What you receive
- Concise executive findings
- Technical review document
- Decision options and trade-offs
- Recommended direction, with rejected alternatives
- Risks, assumptions, and evidence gaps
- Immediate next actions, and a review session
Scope, duration, and fee are agreed before the engagement begins, based on the decision, the evidence available, and the systems in scope.
Discuss a reviewEvidence, alternatives, consequences, recommendation.
-
Frame
Define the actual decision, constraints, stakeholders, and consequences of delay.
-
Examine
Review the architecture, system, proposal, evidence, and operating context.
-
Compare
Evaluate realistic alternatives against cost, risk, capability, and reversibility.
-
Recommend
State the preferred direction, rejected alternatives, and remaining uncertainty.
-
Record
Produce a decision document that can be reviewed, challenged, and acted upon.
The objective is not to produce more documentation. It is to make the decision explicit, defensible, and usable.
What guides our conclusions.
- Evidence before preference
- A preferred technology is not evidence that it fits the decision.
- Constraints before solutions
- The architecture should follow the actual business, operational, and organizational constraints.
- Total commitment matters
- Evaluate implementation, operation, support, licensing, migration, and exit together.
- Reversibility has value
- Options that preserve future choices can be economically preferable even when they are not initially cheapest.
- Uncertainty should be visible
- Missing information, assumptions, and confidence levels should be stated rather than hidden behind certainty.
- No change is a valid recommendation
- A review should not manufacture implementation work when the current direction remains appropriate.
A recommendation that can be examined.
Reviews use a consistent structure so the reasoning can be followed, challenged, and acted upon.
- Decision
- The question being answered.
- Context
- Business objective, constraints, and relevant history.
- Evidence
- Facts, measurements, system observations, and source material.
- Alternatives
- Realistic options considered.
- Trade-offs
- Cost, risk, capability, reversibility, and operational impact.
- Recommendation
- Preferred direction and rationale.
- Uncertainty
- Assumptions, evidence gaps, and confidence level.
- Next actions
- The smallest useful steps that follow from the decision.
Findings remain confidential unless publication is explicitly agreed.
Typical review questions.
-
Architecture second opinion
Is the proposed architecture proportionate to the problem and the team that must operate it?
-
Modernization decision
Should the system be improved incrementally, partially replaced, rewritten, or left unchanged?
-
Vendor proposal review
Are the scope, assumptions, dependencies, operating model, and long-term ownership costs acceptable?
-
AI feasibility review
Is the use case operationally, economically, and technically justified before platform or model commitments are made?
Common questions, answered.
What is an independent architecture review?
An examination of a system by a reviewer with no stake in the implementation that follows. It delivers a written recommendation carrying its evidence and the alternative it rejects, so the conclusion can be examined rather than trusted.
What does a review deliver?
A review document with a fixed structure: the question, the evidence, the findings, the recommendation, the rejected alternative, and the reasoning. It is written to be argued with, and it stands after we leave.
Why keep review separate from implementation?
Because advice that ends in a sales proposal is not advice. Independence removes the incentive to find work, which is what makes the recommendation worth having, and implementation remains a separate decision that is never assumed.
What is technical due diligence?
A review of a target company's technology before a transaction: architecture and code condition, delivery capability, scalability, security exposure, and the dependencies the business quietly rests on, reported with evidence for the deal team.
How is a review scoped?
To the decision that cannot wait. Where a contract or board date is close, the review examines what that decision turns on rather than the whole estate, and the proposal states the scope plainly.
Who commissions technical due diligence?
Investors, acquirers, boards, and lenders: anyone whose decision depends on technology they do not yet own. The report is written for the deal team and stands up to its committee.
Do you work remotely, and in which time zones?
Yes. Reviews run remotely across the EU and North America, with call overlap for European hours and East Coast mornings, and access arranged to fit the deal's confidentiality requirements.
What does a review cost?
Scope, duration, and fee are agreed before the engagement begins, based on the decision, the evidence available, and the systems in scope. The proposal states all three plainly.
Independent review. Separate implementation decision.
ClarusTech reviews and recommends. Any follow-on implementation is separately scoped and never assumed. StratusWorks supports software architecture and engineering when required. CloudLift focuses on cloud cost, infrastructure, and platform efficiency.
- The engagement ends
- with the recommendation. No implementation proposal is attached.
- Referral fees
- None, in either direction. No practice earns on what another sells.
- Implementation
- Considered only when the client raises it, scoped separately, never assumed.
- The report
- Vendor neutral. It stands whether or not any sibling practice is ever engaged.
Make the decision before making the commitment.
Tell us what is being proposed, what is uncertain, and what happens if the decision is wrong. We will help define the review that provides useful clarity.
Architecture reviews · technical second opinions · due diligence · vendor evaluation · consequential technology decisions