Insight · October 2026

Buying a business that runs on software: a technical due diligence checklist

You're buying or investing in an owner-managed business, and its bookings, orders or customer service all run through software. The accounts and the contracts get checked line by line. The technology often gets a demo and a handshake. Here are the questions to ask before you sign.

Why the technology deserves its own check

In a smaller deal there's rarely a technical team on either side. The seller may not know how their own system works, and the person who built it may be a freelancer who left years ago. That's not a reason to walk away. It's a reason to find out what you're taking on, because the cost of fixing it after completion is yours, not the seller's.

Use the questions below as a starting list. Ask for answers in writing, and ask to see evidence rather than take assurances.

Ownership and intellectual property

  • Who owns the code? If a freelancer or agency wrote it, is there a contract that assigns the copyright to the business? Without one, the developer may still own it.
  • Where is the source code, and will you get full access to the repository, with its history?
  • Whose name are the accounts in? Domain names, hosting, cloud subscriptions, app store listings, payment providers and email services should all be in the company's name, not an individual's.
  • Are software licences transferable? Some commercial licences are tied to a named person or company and don't move with a sale.
  • What open-source code is included, and under which licences? Most are permissive, but copyleft licences such as the GPL or AGPL can place conditions on how the software is distributed or offered to customers.

People and key-person dependency

  • Who built it, and who maintains it now? An employee, a freelancer, an agency, or the seller themselves?
  • Will they stay after the sale? If one person holds all the knowledge, their departure is your biggest technical risk.
  • Is anything written down? Documentation, a list of accounts and passwords, a note of how to deploy a change.
  • Could someone else pick it up? Mainstream technology is easier to find developers for than an obscure or home-grown framework.

Code and architecture

  • What is it built with, and is every part still supported by its vendor? Check the language runtime, framework, database and operating system.
  • How much technical debt is there? Ask what the developers would fix if they had the time, and what nobody dares to touch.
  • Are there automated tests? Without them, every change is a risk and every upgrade costs more.
  • How is it deployed? Can the live system be rebuilt from the source code, or does the server hold changes that were never saved anywhere else?

Security and data protection

  • What personal data does it hold, and is it handled in line with UK GDPR? Ask for the privacy notice, the data processing agreements with suppliers, and whether the business pays the ICO data protection fee.
  • Does card data touch the system? If card numbers pass through the business's own servers, PCI DSS applies in full. A hosted payment page from the payment provider keeps most of that burden off the business.
  • Are there backups, where are they kept, and has anyone ever restored one?
  • Have there been incidents? Breaches, outages, ransomware, or reports to the ICO. A personal data breach that's likely to put people at risk must be reported to the ICO within 72 hours of the business becoming aware of it, so ask how that would be handled.
  • Who has access? Former staff and old suppliers with live logins are common.

Hosting and running costs

  • What does it cost to run each month? Hosting, cloud services, licences, subscriptions and support contracts, with invoices to back the figures.
  • Is anything paid on a personal card or hidden inside someone else's account?
  • Is the hosting fit for purpose? An old single server with no monitoring can look like good value right up to the day it fails.
  • What will keeping it current cost? Upgrades are a running cost, not a one-off, and they belong in your valuation.

Third-party dependencies and contracts

  • Which outside services does it rely on? Payment gateways, email sending, address lookup, mapping, accounting links, AI services.
  • Do those contracts survive a change of ownership? Check for change-of-control clauses, notice periods and price rises due at renewal.
  • Is there a support or development contract with an agency? What does it cover, what does it cost, and who owns the work it produces?

Scalability

  • Can it handle the growth in your plan? Twice the customers, a new location, a new product line.
  • Where would it break first? The database, the server, a manual process, or one person's time.
  • Can it integrate with your existing systems, if you're bolting it onto a business you already run?
Red flags: the code exists only on a developer's laptop; domains, hosting or app store accounts are in a former developer's personal name; there's no contract assigning the code to the business; nobody has ever restored a backup; the system runs on out-of-support software, such as .NET 8 after 10 November 2026, Windows Server 2016 after 12 January 2027, or SQL Server 2016, which lost support in July 2026; or the seller can't say who could maintain it after they leave.

None of these has to kill a deal. Most can be fixed, and some cost little to put right. But each has a cost, and you want that cost reflected in the price, covered by a warranty, or put right by the seller before completion. If the system turns out to be an orphan, the guide to taking control of a bespoke system after the developer has left covers what comes next, and an out-of-support .NET application usually needs an upgrade rather than a rewrite: see migrating from .NET Framework to .NET 10.

Choosing a supplier or platform: the same questions, earlier

You don't have to be buying a business to need this. If you're choosing a software package or a development agency, much of the same checklist applies before you commit:

  • Will you own the code, the data and the accounts, or only rent access to them?
  • Can you export your data in a usable form if you leave?
  • Is the technology mainstream and supported, or a proprietary platform only this supplier can work on?
  • Does the proposal say clearly what's included, and what's charged as extra?
  • What happens if the supplier's key developer leaves, or the supplier closes?

A proposal that's vague on ownership or exit is a warning sign, however good the demo looks.

Need a hand?

I've built and supported bespoke business systems for 30 years, including a job, stock and invoicing system that has been in daily use for more than 11 years, and I've rescued a failing e-commerce site left behind by someone else. My technical due diligence gives you an independent, plain-English report on the code, security, hosting, ownership and people risks, with each risk rated and a cost to fix. A supplier or platform review starts from £1,500, and a full acquisition or investment review from £2,500.

Book a due diligence review