Buying a software company, buying an app, or investing in one means buying its code, its hosting and the people who understand both. The financials will not show you whether the code can be maintained, whether the company owns it, or whether one developer leaving would stop it. This checklist covers what to look at before money changes hands.
It is written for owners and investors. You do not need to do every check yourself, but you should get a clear answer to each one before you sign.
This checklist is general guidance, not legal or financial advice. Have a lawyer review ownership, licensing and contract questions.
The checklist
1. Before you start
- Write down the decision date. A review that lands after closing cannot change the deal.
- Agree the scope: which code, which hosting accounts, which third-party services.
- Get read-only access to the code repository and the hosting or cloud account. Nobody on the review should be able to change anything.
- Sign a confidentiality agreement covering the code and the report.
2. Who owns the code
This is the item that most often turns out to be a legal problem rather than a technical one.
- Who wrote the code: employees, contractors, an agency, or a mix.
- Is there a signed agreement assigning each contractor’s and agency’s work to the company? In the US, paying for code does not on its own make you the owner of it.
- Who owns the repository, the domain names and the hosting accounts. They should be in the company’s name, not a founder’s personal account.
- Open-source licenses in use. Most are fine. Copyleft licenses such as GPL and AGPL can, in some cases, require the company to publish its own source code.
3. How it is built and where it runs
- Is there a current diagram or written description of the system? If nobody can draw it, that is a finding.
- Where it is hosted, and in whose account.
- Single points of failure: one server, one database, one person with the passwords.
- Are development, testing and live systems separate?
4. Code quality
What matters is how expensive the next two years of changes will be.
- Are there automated tests, and do they actually run and pass?
- Can someone other than the original developer build and deploy it from the instructions?
- How out of date are the frameworks and libraries? Versions that no longer get security updates are a cost you are buying.
- Large areas of dead or duplicated code, and how much of the code is documented.
5. Security
- Passwords, API keys or other secrets stored in the code or its history.
- How users sign in, and whether permissions are checked on the server, not just hidden in the interface.
- Known vulnerabilities in the libraries it uses.
- Logging: could the company tell what happened after an incident?
- Past incidents and past security tests, with the reports if they exist.
6. Data
- What personal data it holds, where, and who can reach it.
- Backups: how often, where the copies live, and when a restore was last tested.
- Does the privacy policy match what the software actually does with data?
7. Running it
- History of outages and how they were handled.
- Monitoring: who finds out when it breaks, and how.
- How changes reach the live system, and who can make them.
8. People
Small software businesses often run on one or two people’s knowledge.
- How many people understand each part of the system.
- What happens if the main developer leaves after the deal. Is there a handover plan, or a reason for them to stay?
9. Costs
- Every monthly bill the software depends on: hosting, databases, email, third-party APIs and licenses.
- Which of those accounts and licenses transfer to a new owner, and which have to be re-signed.
- How the costs grow with more customers.
10. AI inside the product
Now a standard section.
- Which AI providers the product calls, and what customer data is sent to them.
- Where the AI keys are stored and who can use them.
- What the AI costs per month today, and per customer.
11. The report
What decision makers actually need from all of the above.
- Every finding ranked by severity, in plain language.
- A rough cost to fix the serious ones.
- For each serious finding: fix before closing, fix after closing, or reflect it in the price.
When to bring someone in
Most of these questions can be asked by anyone. Answering them takes someone who can read the code and the hosting setup, and who works for you, not for the other side of the deal.
- See how our technology due diligence works. An independent, read-only review with a written report and a debrief call, at a fixed quote.
- Ask for a quote with your decision date.