Technical due diligence before you sign with a software vendor

A development agency has sent a proposal. An AI vendor has quoted a platform fee and a timeline. Or it was built last year, it is live, and you suspect that what you own is not what you were sold.

You are not technical in this particular way, and everyone who can answer the question is paid by the answer. So: the software, the vendor and the terms, read end to end before you sign — or before you spend another quarter defending a decision made without you.

The one statistic here is not mine. McKinsey, with the University of Oxford, studied more than 5,400 IT projects and found the large ones — eight-figure budgets, far bigger than yours — running 45 percent over budget and delivering 56 percent less value than predicted. The mechanism does not shrink with the budget, and it is nearly always set running before the contract is signed.

I work for the company buying the technology, not the vendor selling it: no commission, no referral fee, no revenue share. It is a term of the contract, not a promise on a website — which is what lets me tell you to keep your current vendor, or build nothing.

Three unrelated industries use the phrase “technical due diligence”, so most technical due diligence services you find advertised are selling into one of the other two. Let me be plain: this is not deal-side work.

If you are acquiring a company, raising a round, or sitting on the investor side of a term sheet, you want a diligence firm built for transactions — one that works to a deal calendar and writes for an investment committee. Several rank directly above this page. They are good at a job I do not do, and I would rather tell you here than in a call you had to book to find out. Same for property: if you came looking for a building survey, that is a different industry borrowing the same three words.

What is left is the version almost nobody writes about — software due diligence for the person paying the invoice. Before you sign. Before the budget goes.

The engagement is the Technical Assessment: your stack, your vendors and your roadmap, read end to end. Five things get read, each as a question about your money.

Architecture, and what it costs to run

Not whether it is fashionable — whether it survives you succeeding. The real monthly bill at your real volume, and what changes at ten times it.

Security, data and compliance

Where your data lives, who at the vendor can read it, and which obligations are being met by a document rather than by the system.

The team, and how work reaches production

How many people have genuinely touched the code, how long a change takes to reach your customers, and how it gets undone when it turns out to be wrong.

AI readiness, and what was generated

Which parts a model wrote, who reviewed them, and whether the AI feature you were sold is a capability or a wrapper with a markup. If AI is the whole question, the AI readiness assessment is the page for that.

What you get on paper

A written assessment opening with the risks in the order they will cost you money, a ranked list of what to fix first, and against each the cost of leaving it alone.

Most of this you can do yourself, this week, without hiring anyone. Here is the technical due diligence checklist I would hand a non-technical owner. The vendor’s reaction to being asked is half the answer.

1. 1

   Ask who owns the code, in writing. Not who wrote it — who owns it. Transfer on final payment, on delivery, or never are three different purchases at the same price.

2. 2

   Ask for access to the repository today. Not a demo — the actual repository, in your name, while the work is still running. A vendor who refuses is telling you about the day you leave.

3. 3

   Count the people who have touched it. Ask for the contributor list with dates. Work built by one contractor who left in March is a different asset from work built by four people still there.

4. 4

   Ask what it costs to run each month. Hosting, third-party services, and per-request model costs if there is AI in it — priced at the customers you actually have, in writing.

5. 5

   Ask what breaks at ten times that volume. A real answer names a specific component and a specific number. “It scales” is not an answer; it is a word.

6. 6

   Ask where your data lives and who can read it. Which country, which provider, which staff and subcontractors hold standing access, and what is deleted when the contract ends.

7. 7

   Ask how a change reaches production — and how it gets undone. Who approves it, what tests run, what the rollback is. One person and no tests means every future change is a gamble you underwrite.

8. 8

   Ask which parts were generated by AI, and who read them. Generated code is not automatically worse. Generated code nobody senior has read is a different proposition, and you are entitled to know which you own.

9. 9

   Ask what handover looks like when you leave. As a written procedure, not a reassurance: repositories, domains, credentials, a data export something else can read, and how many working days.

10. 10

    Ask for two references who stopped using them. Every vendor has happy current clients. The useful call is with someone who left, and a vendor who cannot produce one is choosing what you hear.

Run those ten. If the answers satisfy you, you have saved yourself an engagement. If three come back vague, that is usually when people email me.

It starts with a free fit call and ends in a document you can act on after I am gone; how engagements work sets out the sequence. If one proposal is the only thing blocking you, a Decision Review (2 WEEKS) is the better buy, and everything paid for it is credited against this one within 90 days.

DURATION

3–4 WEEKS

FEE

fixed, invoiced 50/50 · full rates on the rate card

FORMAT

written assessment + one working session

NEUTRALITY

no commission, referral fee or revenue share from any vendor

AVAILABILITY

ONE NEW ENGAGEMENT PER MONTH · NEXT START SEPTEMBER