What you are really buying.
Before investing in, buying or taking over a platform, it is worth knowing what state it is in, what it costs to maintain and what risks come included in the price. I review the technical asset and hand you a report you can take to a board and defend.
A first 30-minute call to understand the deal and its calendar. No price or timeline yet: that arrives in writing.
What a technical due diligence is
A technical due diligence is the independent review of a company's or a project's technology asset before making a decision with money behind it: an investment, an acquisition, a change of supplier or a migration.
It does not answer «is the code well written?». It answers questions you can take to a board: what is there, what it is worth, what it costs to maintain, what risks it carries, and what you would have to spend in the first year just to keep it running the way it runs today.
The financial side of a deal is always reviewed. The technical side almost never is, and that is usually where the hidden cost sits: a platform only one person understands, a dependency without support for years, an integration held together by a script nobody has touched since 2019.
When it makes sense
- You are investing in a company whose main product is software, or whose operation depends on it.
- You are buying a company and the price includes a platform you will inherit whole, with its technical debt and with the people who know how to maintain it — or without them.
- You are buying or adopting a platform and want to know whether the cost of ownership resembles the quote.
- You are inheriting a system because the team that built it is leaving, or because the supplier that maintains it is ending its contract.
- You are migrating and need to know what can be carried over, what has to be rebuilt and what should be left to die.
- You are changing supplier and want to know what asset you are actually recovering.
- You have to decide whether a project is viable and the internal estimates no longer sound credible.
- You are the seller and would rather know what the buyer is going to find before they find it.
What gets reviewed
The state of the system
Architecture, general code quality, test coverage, accumulated technical debt, versions and dependencies, basic security, environments and deployments.
The dependencies
Which third-party software it depends on to run, which are abandoned or unsupported, which tie the business to a specific vendor, and what it costs to leave each one.
The people and the knowledge
How many people genuinely understand the system. What happens if one specific person leaves tomorrow. What is documented and what only lives in someone's head. It is the risk most often overlooked in an acquisition and the one that costs the most.
The real cost of maintaining it
Infrastructure, licences, maintenance contracts, supplier hours and the spend needed in the first year just to sustain what already exists, without building anything new.
The gap between what is said and what is there
What the commercial documentation promises, what is actually built, what is half done, and what is built but nobody uses. You see it in the repository history and in real usage, not in the presentation.
What gets delivered
- An executive report
- Four or five pages a non-technical reader can go through and come out knowing whether to buy, at what price and on what conditions.
- A detailed technical report
- The findings with their evidence, so your team or your adviser can contrast them.
- A risk register
- Each risk with its probability, its impact in euros where it can be estimated, and what it would take to mitigate it.
- An estimate of the cost of ownership
- What it costs to maintain this for a year, exactly as it is.
- An explicit recommendation
- Proceed, proceed while renegotiating the price, proceed with conditions, or do not proceed.
- A presentation meeting
- Where I answer the questions of whoever has to sign.
What decisions it helps you make
- Invest or do not invest.
- Pay the asking price, or pay less because you now have numbered arguments to negotiate it.
- Buy with conditions: hold back part of the payment, require a key person to stay, or ask for certain things to be fixed before closing.
- Migrate now, migrate later or do not migrate.
- Keep the current supplier or change them, knowing what you take with you and what stays behind.
- How much budget to set aside for the first year of an asset you do not yet know.
- Stop the deal. It happens. And it is usually the cheapest thing a report can do for you.
A technical audit and a technical due diligence are not the same thing
They are used as synonyms and they are not. The difference is not in the depth, it is in who it is written for and what for.
| Technical audit | Technical due diligence | |
|---|---|---|
| Written for | The owner of the system | Whoever is putting money in |
| Question | What state is this in and what do I fix? | What am I buying and what is it worth? |
| Looks at | The system | The system, its cost, its people and its risk |
| Ends in | An improvement plan | An investment decision |
| The reader is | Technical | A board, an investor, a committee |
| When it is done | When something is not working | Before signing |
A technical audit tells you what to fix. A technical due diligence tells you whether it is worth buying it in order to have to fix it. If what you need is the former, look at digital project rescue or the initial technical diagnostic.
How the scope gets defined
On the first call I do not close a price or a timeline. I have not seen the project, and estimating without having seen it would not be serious: what a rescue, a due diligence or external technical leadership costs depends on the real state of the system, on what access exists, on how many suppliers are involved, on what documentation there is, and on how urgent it is.
- 01
A first call to understand the situation
Thirty minutes, no cost. You tell me what is going on, I ask questions, and I come out knowing whether I can help and what kind of work fits.
- 02
If it fits, an initial review of the context
I take a first look at whatever exists: documentation, access, contracts, who is involved. This is where the real size of the problem becomes visible.
- 03
Definition of the scope
What is in, what is out, what dependencies exist and what can be left aside without the work losing its point.
- 04
A written proposal
With scope, price, timeline and deliverables. No open ranges: a proposal you can compare and defend.
- 05
We start only if we both approve it
If the proposal does not convince you, no harm done and you have paid nothing. If it does not convince me, I say so first.
I would rather look careful than look fast. A quote given in thirty minutes, without having looked at anything, gets broken by week three.
Before you sign, half an hour.
Tell me about the deal and the calendar. I tell you what would need reviewing and whether this is an engagement for me. If the scope does not fit me, I say so on that same call.
You tell me what the deal is and when the decision has to be made.
If it fits, I review the context and we bound what has to be looked at and what stays out.
The proposal arrives in writing, with scope, timeline and price, before anything starts.
What people ask before commissioning one
How much does a technical due diligence cost?
It depends on the size of the system, on the access available and on the timeline. I cannot tell you on the first call, because I have not seen anything yet. That call is to understand the deal and decide whether it makes sense to move forward; if it does, I review the context, define the scope and send you a closed proposal.
How long does it take?
Deals have dates and I know it. The first thing I ask is when the decision has to be made. The timeline gets closed in the proposal, not on the call — but if I can see from the start that your calendar does not work, I say so right there and we do not continue.
Do you need access to the code of the company I am buying?
Yes, read access at least, and to one or two technical people. It is done under a confidentiality agreement and within the data room process, like any other adviser on the deal.
What if the seller does not grant access?
A limited review can be done with whatever is observable from outside, and the report will state exactly what I could not verify. A report with declared gaps is worth something. A report that pretends it has none is not.
Is it worth it for a small deal?
Yes, with an adjusted scope. For small deals a red-flag review is usually enough: the risks that would make you rethink the deal, without going into the rest.
Can you do it if the system is not eCommerce?
Yes. Most of what gets reviewed — dependencies, concentration of knowledge, cost of ownership, risk — does not depend on the sector. Where I add the most context is eCommerce and systems connected to an ERP.
Do you work with the deal's financial or legal adviser?
Yes, and it is the norm. The technical part is one piece of the same report. I can deliver in whatever format the rest of the team uses.