Know what you're buying — or what you've built

What technical due diligence is — and who needs it

Technical due diligence is an independent, expert look under the hood of a software product before a high-stakes decision. If you're about to acquire a company, lead or join an investment round, or buy out a product, you're partly buying the codebase — and the code is usually the one thing the pitch deck never shows you. My job is to tell you, in language you can actually act on, whether what you're buying is solid, fragile, or a liability dressed up as an asset. It's just as useful the other way around: if you're a founder heading into a raise or a sale, a sanity check before investors send in their own reviewers lets you fix the embarrassing stuff on your own terms and walk in with confidence instead of surprises.

What I assess

I go past the surface and evaluate the things that actually determine whether a product can grow, stay secure, and be maintained by a real team. Every area below turns into concrete findings in the report:

• Code quality & maintainability — is the code readable, tested, and consistent, or a tangle only its author can navigate?
• Architecture — do the major pieces fit together sensibly, and will that structure hold as the product grows?
• Security — exposed secrets, weak auth, injection risks, and the classes of vulnerability that turn into breaches and headlines.
• Scalability & performance headroom — what happens at 10x the current load, and where it breaks first.
• Technical debt — the shortcuts already taken, what they'll cost to unwind, and which ones you can safely live with.
• Key-person & bus-factor risk — how much of this only works because one specific person is still in the building.
• Licensing & third-party dependencies — the open-source and vendor code baked in, and whether any of it is a legal or support time bomb.
• Infrastructure & running cost — how it's hosted and deployed, and what it realistically costs to keep the lights on and scale up.

What you get: the report

The deliverable is a written report you can actually use — not a wall of jargon that needs its own translator. Every finding is severity-ranked, so you know instantly what's a red flag, what's a fix-it-later, and what's simply noise. Up front sits a plain-English verdict: a clear read on whether the product is a green light, a green light with conditions, or a walk-away — and why. Wherever something is broken, I say what it would take to fix it and roughly what that costs, so the report feeds straight into your valuation or negotiation. We close with a follow-up call where I walk you through the findings and answer whatever the deal or board really needs answered.

How it works and how long it takes

I work to a fixed scope agreed up front, so there's no open-ended meter running while a deal clock ticks. We start with a short call to understand the stakes and the deadline, then I get read access to the code, infrastructure, and whatever documentation exists. From there I do the hands-on review, cross-check the risky areas, and write it all up. Most engagements run from a few days to a couple of weeks depending on the size of the codebase and how deep you need me to go — and I'll tell you which before we start, not after. You get the written report first, then the walkthrough call.

Why work with me

I'm a hands-on developer with 20+ years of shipping and maintaining real software, and I read the actual code — not the slideware, not a self-reported questionnaire the founder filled in. I've built and scaled products under genuine load, including aticketing platform that handled 20,000+ registrants, a mobile app that grew past 200,000 downloads, and a news platform tuned for 200,000 daily visitors. That means when I flag a scaling risk or a shaky bit of architecture, it's grounded in having lived through the same problems, not read about them. I'm independent, I have no incentive to make a deal look better or worse than it is, and I say it straight.

The higher-stakes sibling of a code audit

If you just want to understand and improve your own product, mycode audits cover that. Technical due diligence is the higher-stakes version of the same work: same deep read of the code, but framed around a transaction, with the added focus on deal risk, valuation impact, and the questions an investor or acquirer needs answered before money changes hands. When the outcome of the review decides whether a deal happens — and at what price — that's when you want due diligence, not just an audit.