08Technical Strategy
A defensible answer to an expensive question.
Architecture review, build-versus-buy analysis, technical due diligence and modernisation planning — delivered by engineers who will still be there when the decision is implemented.
01Where it starts
What we usually walk into.
Significant technical decisions are made with incomplete information, under time pressure, often on advice from a party with an interest in the outcome. The consequences appear years later.
We need to decide whether to rebuild or refactor, and both answers have advocates.
A vendor has proposed a platform and we cannot independently assess the claim.
Delivery is slow and we do not know whether the cause is architecture, process or team.
We are acquiring a company and need to understand what we are buying technically.
We committed to a modernisation programme without a sequenced plan.
02Approach
How we do the work.
A structured, independent assessment with the options, trade-offs, costs and risks written down, so the decision can be defended to a board and revisited when circumstances change.
- 01
Evidence over opinion
We review the code, the delivery metrics, the incident history and the architecture, and we talk to the engineers doing the work. Conclusions are traceable to what we observed.
- 02
Options, not a single recommendation
You get two or three viable paths with their cost, risk, timeline and reversibility — plus our recommendation and the conditions under which it would change.
- 03
Written for two audiences
One document, two readable levels: a business-language summary for the board and full technical reasoning for the engineers who will implement it.
- 04
Sequenced, fundable plan
Modernisation plans fail when they require eighteen months before anything ships. We sequence work so value and risk reduction arrive early and funding decisions stay reversible.
Capabilities and deliverables
Capabilities
- Architecture assessment and review
- Technical due diligence
- Build-versus-buy and vendor evaluation
- Modernisation and migration planning
- Delivery process and capability assessment
- Cost and risk modelling
- Technical governance design
What you receive
- Architecture assessment with findings and evidence
- Options analysis with cost, risk and timeline per path
- Technical due diligence report
- Build-versus-buy analysis
- Sequenced modernisation roadmap
- Delivery capability assessment
- Board-level briefing and Q&A session
Common use cases
- Rebuild versus refactor decisions
- Platform and vendor selection
- Technical due diligence before investment or acquisition
- Post-acquisition integration planning
- Engineering capability and delivery assessment
- Architecture review before a major programme starts
Technologies typically involved
- Stack-independent — assessments cover whatever is in place
- Common estates: Java, .NET, Go, Python, Node.js, PHP
- Cloud: AWS, Azure, Google Cloud, on-premise and hybrid
- Data: PostgreSQL, Oracle, SQL Server, MongoDB, Kafka
03Engagement
How it runs.
- 01
Framing
3–5 days
The decision to be made, the constraints, and what a good answer must contain.
- 02
Assessment
2–4 weeks
Code, architecture, delivery data and stakeholder interviews.
- 03
Analysis
1–2 weeks
Options modelled with cost, risk and timeline; recommendation with conditions.
- 04
Briefing
1 week
Presentation to leadership and engineering, followed by a written final report.
04Security
Security considerations.
These apply to this service specifically. They are engagement conditions, not aspirations, and we will put them in the contract.
- Security posture is part of every assessment, not a separate engagement
- Due diligence covers licence compliance and supply-chain risk
- All material is handled under NDA and destroyed on an agreed schedule
- Findings are shared only with named recipients you nominate
05Outcomes
What changes afterwards.
A decision your leadership can stand behind, and a plan your engineers can execute.
- 01
A decision that can be defended to a board with written reasoning
- 02
Reduced risk of an expensive, hard-to-reverse technical commitment
- 03
A modernisation plan that is fundable in stages
- 04
Alignment between what the business needs and what engineering is building
06Questions
Asked before every engagement.
Not by default. Advisory engagements are priced and scoped independently, and the recommendation is written to be executable by your team or another supplier. If we are a good fit for the delivery we will say so, and you should weigh that accordingly.
Two to four weeks for most transactions, depending on estate size and data-room access. We can run a compressed one-week version where the timetable requires it, with the reduced confidence stated explicitly in the report.
Where it is in scope, yes — delivery capability, ownership and process are frequently the real constraint rather than the architecture. We assess practice and structure, not individuals.
Frequently runs alongside
Ready to scopetechnical strategy?
Bring the problem, the constraints and the deadline. We will tell you what is achievable, what it costs and what we would do first.