Technical Diligence: What to Check in the Code Before You Buy

Technical diligence on a small acquisition is not a code review. You are not grading the seller's taste. You are answering five questions about whether this thing will still be running in a year with you at the wheel.

Question 1: Can you run it?

Clone the repo, follow the README, get it running. This single exercise finds more real problems than any amount of reading. If there is no README, or the setup requires a call with the seller, you have learned something important about your first month of ownership.

Question 2: What happens when it breaks?

• Is there any monitoring, or does the founder find out from a customer email?

• Where do the logs go, and how long are they kept?

• What's the actual backup schedule — and has a restore ever been tested?

• How many single points of failure are there? One server with no image is a business with a fuse lit.

Question 3: What's rotting?

Check the dependency manifest against current releases. A handful of minor versions behind is normal maintenance. Three unmaintained packages doing security-sensitive work is a project you'll be rewriting on someone else's schedule.

Also check the runtime itself. A stack pinned to a version that's already past end-of-life is a forced migration in your first quarter.

Question 4: What's hard-coded?

Grep for keys, tokens and passwords in the repo. You should assume every credential in the history is compromised the moment you have access, and rotate all of them at handover regardless. What you're really checking is whether the seller's operating standard is going to cost you a weekend.

Question 5: Can you hire for it?

The most under-priced technical risk is not bad code — it's unusual code. A boring stack you can hire three contractors for is worth a real premium over a clever one you can't. If you can't maintain it and can't hire for it, the price should assume a rewrite.

The 90-minute checklist

1. Clone, install, run. Time it.

2. Read the last 100 commits — is this maintained or abandoned?

3. Dependency audit: how much is unmaintained or EOL?

4. Grep for secrets.

5. Find the deploy process. Is it a script, or is it tribal knowledge?

6. Ask for a database schema dump and skim it for the shape of the domain.

7. Ask: "what's the thing in here you'd warn a new owner about?" Good sellers answer honestly, and the answer is worth the whole call.