What is technical due diligence when buying a software company?

It is the work of finding out what you are actually acquiring before the price is fixed, and it is not a code review. Five questions decide almost everything. Can the software be changed, measured as how long a competent engineer who has never seen it takes to get a small change safely into production. Can it be run without the person who built it, meaning a build that works on a clean machine, a deploy that is written down rather than remembered, and environments that can be recreated. Is it legally yours, which covers contractor IP assignment and every account, domain, store listing and phone number that may still sit in a personal name. What does it depend on that you do not control, because a product that is a thin layer over one vendor has that vendor's pricing inside its margins. And what obligations arrive attached to the data, including retention duties, the consent basis of a marketing list and any regulated records. Code style, framework age and test coverage matter far less than buyers expect, and they absorb most of the attention.

What are the biggest red flags when acquiring a codebase?

Five findings are worth real money at the negotiating table. One person is the system, usually an excellent engineer who has held it together alone, so the handover period and whether they stay through it have to be priced. Production cannot be reproduced from the repository plus documented configuration, which means you are buying a running instance and hoping rather than a system. Accounts, domains and intellectual property sit in personal names, which is fixable but needs the cooperation of people who stop returning calls after a close, so it belongs in the agreement rather than a follow-up email. The margin belongs to a vendor whose pricing or terms were never negotiated. And the data carries obligations nobody has discharged, such as no consent record, no retention policy or regulated records sitting in ordinary storage. How the seller responds to a simple day-one access request is itself a finding: full repository history within a day is a good sign, while a zip file and a promise of access after signing is a different signal entirely.

Our developer left and nobody can change our software. What should we do first?

Resist the instinct to commission a rebuild, because it is usually the most expensive way to solve a problem you have not measured yet. Run a five-day drill instead, with one engineer who has never seen the system. Clone it and build it on a clean machine, and time how long that takes, since anything past a day means an undocumented setup lived in somebody's head. Deploy it to an environment you own rather than the one it is running in, which is the most revealing step of the exercise and where most handover claims quietly fail. Trace one real transaction end to end, following it through every system it touches, because that is where undocumented integrations and surprise costs concentrate. Make one small change and ship it, since the elapsed time is your multiplier for everything else you want to do. Then collect the accounts: every third-party service, domain, store listing and number, with the name each one is registered to. After that week you will know whether you need a rebuild, a maintenance arrangement or simply a second engineer who knows where things are.

Technical Due Diligence: What to Check Before You Buy Software You Did Not Build

TL;DR: Technical due diligence is not a code review. You are answering five questions: can the software be changed, can it be run without the person who built it, is it legally yours, what does it depend on that you do not control, and what obligations arrive attached to the data. The cheapest version of the whole exercise is a drill rather than a report. Have someone who has never seen the repository clone it, build it, deploy it to a fresh environment you own, and trace one real transaction end to end. What that takes, and what breaks along the way, tells you more than a month of reading code.

Two calls bring people to this. In the first, someone is about to buy a product, a company or a book of customers, and the software is the thing they are paying for. In the second, nobody is buying anything: the agency wound down, the developer stopped replying, the founder who wrote it moved on, and a business is now running on software it cannot change. The questions are almost the same. The difference is that one of you can still adjust the price.

Three situations, three different depths

You are acquiring it. Everything transfers, including the parts nobody mentioned: the accounts, the contracts, the data and its obligations. This is the deepest version, and it is the one where findings are worth real money, because every answer either adjusts the price, moves money into escrow or adds a condition to the close.

You are investing or partnering. You mostly care whether the roadmap you were shown is buildable at the speed you were promised, and whether the team can absorb the money without the system falling over. Plumbing matters less. Team, delivery history and the one or two architectural decisions that cap growth matter more.

You inherited it. There is no negotiation and no price to adjust, so diligence becomes triage. What can we still run, what can we still change, what can we recover if it goes down on Friday, and what is the smallest amount of work that removes the single biggest risk. Teams in this position often jump straight to talking about a rebuild, which is usually the most expensive way to solve a problem they have not measured yet.

Pick the depth by asking what decision an answer would change. If a finding cannot move the price, the timeline or the plan, you do not need to pay anyone to go and find it.

You are not assessing code quality

Code quality is the thing everybody asks about and the thing that decides the least. Five questions decide much more.

Can it be changed? The real measure is how long it takes a competent engineer who has never seen this system to get a small change safely into production. A week is healthy. A month means the knowledge lives in people rather than in the work, and you are buying a training obligation. Indentation and naming have almost nothing to do with it.

Can it be run without the person who built it? Most software works. The question is whether it can be built, deployed, configured and recovered by somebody else. That means a build that runs on a clean machine, a deploy that is written down rather than remembered, environments that can be recreated, and secrets that live somewhere other than one laptop.

Is it actually yours? Contractor agreements without IP assignment, an app store listing under a personal account, a domain registered to an ex-employee, phone numbers registered to an agency. Code is the easy part of ownership and the part everyone checks. The accounts around it are where transfers stall, which is the same argument we make about ownership and handover on work we deliver ourselves.

What does it depend on that you do not control? Every system rests on someone else's platform, and you are buying those terms too. A product that is a thin layer over one vendor has that vendor's pricing inside its margins. Software distributed as an SDK inside other people's apps, the way we built the Repocket SDKs for Geonode, carries a specific version of this: you cannot force anyone to upgrade, so old versions stay live for years. If there is an AI model in the product, ask what happens when the provider deprecates it, and whether swapping models is a config change or a rewrite.

What arrives attached to the data? You are acquiring personal data, retention duties, the consent basis of a marketing list and sometimes regulated records. A customer database assembled without a lawful basis is a liability wearing the costume of an asset. Financial history raises the bar again, for the reasons in building financial software: if the ledger has never been reconciled, you are inheriting the discrepancy.

Ask for these on day one

A short list, sent early, does more work than a long questionnaire sent late.

Read-only access to the repository with full history, not a zip file of the current state.
A list of every third-party account the product touches, with who each one is registered to.
How a change gets to production today, described by whoever last did it.
The last twelve months of incidents, outages and support escalations.
A dependency and license inventory, plus any commercial licenses in use.
The data model, and one real export with the sensitive fields removed.
Forty-five minutes with the person who knows the most, without their manager in the room.

How that request is answered is itself a finding. Full history in a day is a good sign. A zip file, a slide deck and a promise that access comes after signing is a different signal, and it is the one buyers talk themselves out of most often.

Git history in particular is the highest-signal artifact you will get, and the one people forget to ask for. It shows you who actually worked on this, whether activity was steady or came in three panicked weekends, which files churn constantly, and whether the last six months were features or firefighting.

The drill that beats a report

A written assessment describes the system. A drill tests it. Five days, one engineer who has never seen the code.

Clone and build it on a clean machine. Time it. Anything past a day, and the system has an undocumented setup living in someone's head.

Deploy it to an environment you own. Not theirs. This is the single most revealing step in the whole exercise, and it is where most claims of a clean handover quietly die, usually on a service registered to a person or a configuration value nobody can explain.

Trace one real transaction end to end. A signup, an order, a call, an invoice. Follow it through every system it touches. You will find the integrations nobody listed, which is where surprise costs concentrate.

Make a small change and ship it. One field, one label, one rule. The elapsed time is your estimate multiplier for everything on the roadmap.

Then interview. With the first four steps behind you, you know enough to ask questions that cannot be answered with reassurance.

Findings that change the price, and findings that do not

Five findings are worth real money at the negotiating table.

One person is the system. Not a bad engineer, usually an excellent one who has held it together alone. Price in the handover period and whether they will stay through it. This is why acquirers often want augmented engineers embedded before the close rather than after.
The deploy cannot be reproduced. If production cannot be rebuilt from the repository plus documented configuration, you are not buying a system, you are buying a running instance and hoping.
Accounts and IP sit in personal names. Fixable, but it needs the cooperation of people who stop returning calls after a close. It belongs in the agreement, not in a follow-up email.
The margin belongs to a vendor. Fine if you know it going in. Expensive when the model assumed vendor pricing that was never negotiated.
The data carries obligations nobody has discharged. No consent record, no retention policy, regulated records in ordinary storage.

And three that buyers over-weight, reliably.

Ugly code is cheap to live with when it is understood and covered where it matters. An old framework is boring, not dangerous, unless it is genuinely unsupported and taking no security patches. No tests is a real cost, but it is a schedule item you can price, not a deal breaker, and the actual requirement is being able to verify a change rather than a coverage number.

Spend your leverage on the first five. The second three are budget lines.

Questions to ask before you sign

How long until our own engineer can ship a small change? Ask for the number, then run the drill and compare.
Who can deploy today, and what happens if they are unavailable for a month?
Which accounts, domains, numbers and store listings transfer, and whose names are on them now?
Which single vendor would hurt most if its price or terms changed?
What data are we acquiring, on what basis was it collected, and what are we obliged to delete?
What broke in the last year, and how was it found? A system with no incident history is usually a system with no monitoring.
What did the team want to fix and never get funded for? The most honest architecture review you will get, free.

The bottom line

The goal is not a clean bill of health, because no system gets one. The goal is a list of what you are taking on, priced, with the two or three items that could actually hurt separated from the long tail of things that are merely untidy. Most software that looks alarming is ordinary software that grew fast, and we have both built systems like Fyuel, where customers, suppliers, tankers, ledgers and banks have to agree in real time, and picked up systems written by people who had already left. The pattern holds: the code is rarely the problem. Ownership, reproducibility and the obligations hiding in the data are the problem, and all three are knowable in a week.

Buying, investing in or stuck with software somebody else wrote? Book a demo and we will run the drill with you, then tell you plainly what is worth fixing, what is worth pricing in and what is fine as it is. See our work: Fyuel, Geonode, LectureNotes AI and more.