Technical Due Diligence

When you buy or invest in a business, financial and legal checks are routine. If the company's value sits in its software, the technology needs checking too. It may be well built, or it may be a set of shortcuts that only one developer understands.

A technical review answers practical questions. Does the product work as described? Can it handle growth? Who built it, and who can maintain it? Is customer data handled safely? Is anything about to break, expire or become expensive?

Investors reviewing a startup before funding. Buyers who need to understand what they are buying. Companies about to sign a large contract with a technology vendor. Founders who want to find the weak points in their own product before an investor does.

If your question is smaller, such as whether a vendor quote is fair, the Tech Second Opinion is a lighter option.

We agree the scope first. A typical review covers:

• How the product is built: the overall design, and where it will come under strain.
• Code quality and technical debt: how hard it is to change the product safely.
• Servers and hosting: environments, backups and recovery.
• Security basics: who has access, where passwords and keys are kept, and known weak points.
• How personal data is handled, with observations noted for your counsel.
• Dependencies: the outside software, open-source licences and third-party services the product relies on.
• How the team works: releases, testing, documentation and who holds the knowledge.

We agree the questions, the scope, the access we need and the confidentiality terms. Then we collect material: code repositories, diagrams, server details, contracts and a walkthrough with the people who built the product. We read the code and the setup, check key claims against what is really there and talk to the technical team.

The report opens with a short summary for readers who are not technical, then lists findings in order of importance. Each finding carries its evidence and an indication of the effort to fix it.

A board member can read it and an engineer can check it. It keeps facts apart from opinions. It states problems without hiding or exaggerating them, and it says what we could not check. It ends with a clear view: which risks should change your decision, which should change the price or terms, and which can wait until after the deal.

• Secure by default: we use read-only access wherever possible, work under a confidentiality agreement, and remove our access when the review ends.
• Built to scale: we look specifically at whether the product can carry the growth your plan assumes, not only whether it works today.
• Tested before it ships: key claims are checked against the code and the running system, not taken from the pitch deck.
• Looked after after launch: if you go ahead, we can help fix issues, run the handover or guide the new owners, and the findings are written so any team can use them.
• Small changes handled, not invoiced: a follow-up question from your board about a finding gets answered, not billed as new work.
• Honest advice: if we have worked on the product ourselves, we tell you and suggest an independent reviewer.

The report is often the start, not the end. Ongoing guidance after a deal is the work of a fractional CTO. A product that needs saving goes to product rescue. Hosting findings lead to Digital Infrastructure, and deeper security work, including certification readiness, to Trust, Security & Compliance. Some businesses stop at the report, which is fine. The ones that continue keep the same team that already knows the product.

If you need a formal security certification or a legal opinion, those go to accredited partners and counsel. If you have only a few days and the product is large, we will say what we can and cannot cover before you rely on it.

Tell us about the deal and the decision date.