Five questions to ask a seller before anyone reads the code

Buying a small software business usually means buying code that nobody on your side has read. The financial checks cover revenue and costs. The legal checks cover contracts. The software itself, the thing customers actually pay for, often goes unexamined until after completion, when its problems are yours.

You don't need to read code to reduce that risk. If you've read Read the bill before you read the code, you'll already check who holds the accounts, what the bills say and whether any keys have leaked. These five questions go further. Ask them in writing before you commit. They take the seller an hour to answer properly, and how they answer matters as much as what they say.

Vague answers are an answer.

1. Could someone other than you ship a change tomorrow?

Ask the seller to describe, step by step, how a small change gets from an idea to live customers: where the code lives, how it's tested, who deploys it and how. Better still, ask them to show you on a call.

What to look for: steps that only exist in one person's head, deployments done by hand from someone's laptop, and phrases like "I just know which bits not to touch". If nobody else could ship a fix next week, you're buying a business that depends on the seller staying.

2. What have you promised that isn't built yet?

Ask for every commitment made to customers: features promised on sales calls, custom work for big accounts, lifetime deals, uptime promises, discounts that renew, and anything on a public roadmap that customers have paid towards.

What to look for: promises that live in emails rather than contracts, a large customer whose renewal depends on a feature that doesn't exist, and lifetime deals that keep costing you to serve with no more revenue. Every unbuilt promise is a cost you're taking on.

3. Who has worked on the code, and who still has access?

Ask who has written or changed the code in the last twelve months, whether they're still involved, and who can still log in to the code, hosting and database today. Ask how much came from templates, outsourced developers or AI tools.

What to look for: one person who understands everything, especially if that person is leaving. Ask how many hours of handover support the seller will give after completion, and whether it's paid. Former contractors who still have access should lose it on the day you take over.

4. What does it depend on that you don't control?

Ask for every outside service the product can't work without: the platform it was built or hosted on, payment and email providers, AI models, data feeds, app stores and any single partner integration.

What to look for: a product that only runs inside one no-code or AI builder, costs that rise sharply with an outside provider's price changes, terms of service that forbid what the product does, and open source licences that limit how you can use or sell it. A business can be profitable today and fragile tomorrow because of a supplier it doesn't control.

5. What happens to the data on a bad day?

Ask what personal data the product holds, where it's stored, and who can see it. Then ask: if the database were deleted tonight, how long until customers are back, and when did anyone last restore a backup to prove it works?

What to look for: nobody sure what data is held or where, a privacy policy that doesn't match reality, and backups that have never been restored. A backup that has never been tested is a hope, not a backup. Ask too whether the business has ever had to tell customers or the Information Commissioner's Office about a data incident.

Using the answers

• Get them in writing. Answers given on a call are easy to forget and hard to rely on. Your solicitor can tell you which ones should become formal statements in the sale agreement.
• Agree the handover before completion: the accounts that will transfer, the support hours the seller will give, and a commitment to change every password and key once you take over.
• Treat refusals as information. A seller who won't answer, or won't give read-only access to the code for a short review, is telling you something, whatever the reason.

None of this replaces someone actually reading the code. It tells you whether that's worth paying for, and where to point them first.

Robert Udah is principal engineer at Holdfast, which runs fixed-fee technical due diligence for buyers and sellers of small software businesses. See what a deal review covers or download a sample deal review.