Know what you are buying before you acquire a company or software

You are about to acquire a company, invest in a software business, or buy an online store with its own platform. The numbers are checked, the lawyer has read the contracts, and the demo looked good. But nobody on your side of the table knows what is under that demo. Whether the code can still be maintained in two years, whether one developer holds everything in their head, whether the hosting contract happens to expire this month: none of that is in the annual accounts.

When you need a technical due diligence

You need one when software is a real part of the value you are buying. That applies to a wholesaler with its own ordering portal, an accounting firm that had a client tool built, a logistics company with a self-written planning system, or a startup where the product is the whole company. It also applies when you take over a vendor that has run your systems for years, or when an investor sits at your table and runs their own review.

A financial due diligence tells you what the company earns. A legal one tells you which obligations you inherit. The technical one tells you what it costs to keep delivering the product after the current owner walks away. The three belong together. Whoever skips the third finds the technical debt only when the first failure comes, and the one person who could fix it works somewhere else.

What we review: code, infrastructure, people, and contracts

We start with the source code. Not to read every line, but to see how it was built: which languages and frameworks, how old those versions are, whether tests exist, and whether a new developer can start working with it within a few weeks. We look at the version history, because it shows who really worked on it in recent years and how often something broke. Then the infrastructure: where it runs, who has the passwords, what happens if the server goes down, and whether the data stays in the EU, as the company's clients were probably promised.

Then the people and the paperwork. We talk to the technical team without the seller present and hear how they think about the product. We read the licenses, the hosting contracts, and the agreements with outside developers, and we check whether the company actually owns the code. Surprisingly often it does not, because the agency that once built it never transferred the copyright. This is exactly the kind of point that vendor selection and tendering should settle up front, and in an acquisition it has to be settled now.

A report you can use in the negotiation

You do not get an eighty-page technical file that only a developer understands. You get a report that opens with one page in plain language: this is what exists, this is what it is worth, these are the risks, and this is what it costs to remove them. Each risk gets a severity and an estimate of the cost to fix, so you can set it against the asking price. An outdated framework is annoying but manageable. A database without a backup or a product that depends on one person is a different conversation.

The report ends with concrete conditions for the purchase agreement: what transfer of rights is needed, what knowledge transfer you should agree on, and what guarantees you want about open security issues. We explain it to you and to your accountant or lawyer, and we stay available until the deal is signed. We tell you what we find right away, even if it makes the deal less attractive than it looked.

Also as a seller, and what comes next

The same review works on the other side of the table. If you plan to sell your company in a year or two, it is better to know now what a buyer will find. We run the same review, and you get a list of what you can clean up beforehand: missing documentation, rights that still need transferring, a developer who needs to share their knowledge. That saves more in the negotiation than it costs.

After an acquisition, the report is a work list from day one. Some buyers pick it up with their own team. Others ask our fractional CTO to put in a day a week, or have us write an IT strategy and roadmap for the combined company. Either is possible, and neither is required. The report is yours, like everything we write for you, and you decide who works on it next. It starts with a free intake where we hear what you want to buy and how much time there is.