
Technical Due Diligence: What I Look For Before Taking on Advisory Work
H M Husnain
July 1, 2026 · 4 min read
In this article
Before taking on an advisory or fractional CTO engagement, I want a real, honest picture of the current technical state of the business, not a pitch about where things are headed. The gap between those two is usually where the actual risk lives.
What I actually look at
The current codebase, if there is one, not to judge it, but to understand what decisions were made under what constraints, and which of those constraints still apply today. The existing team's technical capacity and how decisions currently get made, since an advisory engagement has to fit into how the business actually operates, not an idealized version of it. Where the business is most exposed technically right now, a single point of failure, an undocumented critical process, a dependency on one person who holds knowledge nobody else has. And how technical decisions have historically been made, by committee, by one person, ad hoc, since that tells me more about what kind of advisory relationship will actually work than anything in a pitch deck.
Why this matters before agreeing to anything
Taking on advisory work without this picture means giving advice that sounds right in the abstract but doesn't account for real constraints, a system nobody documented, a team with different skills than assumed, a business risk nobody flagged because it had become invisible through familiarity. Advice that ignores those constraints isn't useful, however sound it is in theory.
What this process looks like in practice
A handful of direct conversations with whoever actually touches the technical side day to day, not just leadership. A look at what's actually running in production, not just what's documented. And an honest conversation, early, about where things are genuinely fragile, since that's usually the information a business is least eager to volunteer and most important for me to have.
The point of doing this upfront
This isn't about finding reasons to say no. It's about making sure that when I do say yes, the advice that follows is grounded in what's actually true about the business, not what would be true in a cleaner, simpler version of it.
Working on something similar?
I take on a limited number of engagements at a time. If this resonates with a project you're planning, let's talk about it.
Get in Touch
