Focus area
Technical Assessment
I review the technical side of a product or project in the context of the business goals, known problems, and decisions you need to make.
The result is a clear view of what is working, where the risks are, and what I would change.
When to bring me in
You are preparing for the next funding round and want a technical due diligence before investors start asking the same questions.
You have recurring bugs, incidents, or failures and need to understand the root cause rather than keep treating the symptoms.
You are about to make an important technology decision and want an independent view before committing to it.
You are concerned about the architecture, engineering team, or delivery, but do not yet have a clear picture of what is wrong.
You need to know whether the current system and engineering setup can support what the business plans to do next.
What I look at
I start with the business goals, known problems, constraints, and the decisions the assessment needs to support.
From there I look at the architecture, technology choices, engineering setup, delivery plan, and the parts of the system that matter for the question at hand.
I also look at how these fit together. An architecture can be technically sound and still be the wrong choice for the size of the business, the team available to maintain it, or what the product needs to do next.
How I work
I first agree on the questions the assessment needs to answer and what decisions depend on them.
Then I review the relevant architecture, code, documentation, delivery plans, and engineering setup, and speak with the people involved where needed.
I compare what I find with the business goals and constraints, identify the main risks and trade-offs, and form my own view of what I would keep, what I would change, and what needs attention first.
How deep I go depends on the question we need to answer and what we need to understand before moving forward. Sometimes the right answer requires going into the code and architecture; sometimes the bigger issue is in the team setup, delivery plan, or assumptions around the product.
What you should have after this
You should have a clear view of where things stand, which risks matter, and which ones do not need your attention right now.
You should also know what I would change, what I would leave alone, and which decisions need to be made before moving forward.
Where useful, I turn that into a practical set of next steps that your team can work from.
Engagement options
Technical assessments are usually project-based, with a defined question, scope, and delivery window.
For ongoing architecture, vendor, hiring, or engineering decisions, the same kind of independent technical input can also be provided through Technical Advisory.
Practical resources
The Questions Behind a Good Architecture Review
A practical framework for the business and technical questions that should be explored during an architecture review — to clarify constraints, expose gaps and support a defensible decision.
Ready to talk?
If you need an independent technical view before making an important decision, get in touch or book a call.
Taking on up to three new startup engagements in Q3 2026.