Illustrative sample · a fictional system, not a client's

Technical due diligence: the stock-tracking software

Prepared by John Karanja · fixed scope · Sample, November 2026

Technical due diligence for a buyer of a small software business. It sells stock-tracking software by subscription to independent shops with more than one branch. Two developers maintain it: the founder and a part-time developer. The review checks the seller's technical claims against the system. It sets out the risks, open questions and handover problems before signing. Out of scope: valuation, investment advice, legal ownership opinions, financial audit and a complete code or security audit.

Summary

The product works. The database holds 84 subscriber accounts marked active, which matches the seller's figure. Two things do not match the deck. The code repository and the cloud account are registered to a former contractor, not the business. And the "real-time" stock sync runs only once a night. Customer data is backed up every night but has never been restored. On technical grounds, none of these needs to stop the deal. But each should be settled before signing. The decision to buy, and the price, stay with the buyer and their advisers.

Sound: a working product with tested stock and billing logic, and a clear data model.
Fragile: the business does not control its own code, and only the founder can release updates.
Do first: make the transfer of the repository and the cloud account a condition of signing.

Scope and method

In scope: the code, the hosting and domain accounts, the customer database, backups, the release process and the technical claims in the seller's deck and sale documents. Not in scope: valuation, revenue or customer contracts, legal ownership of the code, financial audit, penetration testing and a line-by-line code audit.

Materials reviewed:

The seller's 18-slide deck and the technical section of the sale documents.
Read-only access to the code repository, granted for the review.
A read-only view of the cloud account's resources and six months of hosting invoices.
The database structure and row counts, with no customer records.
The sync job's settings and its log for 1 to 30 September.
Two calls with the founder and the part-time developer, and written answers to 22 questions.

Evidence has three labels. Observed: I saw it in the materials, and I name the source. Reported: the seller told me, and I did not check it. Unknown: the evidence was not available. I never count an unknown as zero.

The map

Seller's deck 2 The deck and sale documents describe the product. They claim "real-time" stock sync across branches.
Code repository 1 One repository with four years of history and 2,900 changes, owned by a former contractor.
Hosting accounts The cloud account runs two servers and the managed database. The domain is held separately, in the business's name.
Customer data 3 One database holds stock records for every subscriber. It is backed up nightly, but the restore has never been tested.
Handover What would move to the buyer at signing: code, accounts, domain and knowledge, today written down in one three-page note.

Findings

1. The code belongs to someone else

High

Evidence: Observed. The repository and the cloud account are registered to a former contractor, who made 1,770 of the 2,900 changes in the first three years. The cloud bill goes on the contractor's card, then is charged to the business monthly. Reported: the contractor "has agreed to transfer". No written agreement is in the data room.
Impact: Without the transfer, the buyer may be buying a licence, not a product. The contractor could remove access at any time. Legal ownership is for the buyer's lawyers. This finding is about who controls the systems.
Unknown: Nothing important.
Recommendation: Make the transfer of both a condition of signing.
Done when: At signing, the buyer's own administrator holds owner rights on the repository and the cloud account. The contractor's access is removed.

2. "Real-time" runs once a night

High

Evidence: Observed. The sync job runs once a day; the deck says real-time. It starts at 02:00. Its log shows 30 runs in September, taking 47 minutes on average. Slide 7 and section 3 of the sale documents both say "real-time stock sync across branches".
Impact: Customers see yesterday's stock in other branches. Any plan that relies on real-time sync, such as selling to larger chains, rests on a feature that does not exist.
Unknown: Nothing important.
Recommendation: Correct this assumption in the valuation, or require the fix before closing. The team should estimate the work. My rough view: weeks, not days.
Done when: Either the sale documents are corrected in writing, or a stock change in one branch appears in another within 60 seconds, shown on live data.

3. Customer data has never been restored

Medium

Evidence: Observed. Backups run nightly, and 14 are kept. No restore is recorded, and neither developer could remember one.
Impact: If a restore fails after the deal, the buyer carries the loss of every subscriber's records.
Unknown: Whether a restore works, and how long it takes.
Recommendation: A witnessed restore test before signing.
Done when: The latest backup is restored to a separate database in front of the buyer's representative. The row counts of the five main tables match the live database. The time is recorded.

4. Only the founder can release

Medium

Evidence: Observed. The release log shows 112 releases in 12 months, all by the founder, from the founder's own computer. There is no written release procedure.
Impact: If the founder left after the deal, all change to the product would stop.
Unknown: How long the founder will stay after the deal.
Recommendation: A written release procedure, and a handover period for the founder, agreed in the deal.
Done when: The part-time developer makes one release from the written procedure, without the founder's help.

5. The running cost is higher than stated

Medium

Evidence: Observed. The deck says hosting costs about USD 900 a month. The invoices show USD 1,140 to 1,260 over the last six months. One of the two servers has run below 2 per cent of its capacity for 30 days.
Impact: A running cost nobody can explain usually grows after the deal, not before.
Unknown: What the idle server is for. The founder was not sure.
Recommendation: An itemised bill from the cloud account, and a decision on the idle server, after the transfer.
Done when: One month's bill names every resource and what it is for.

6. The main framework no longer gets security fixes

Low

Evidence: Observed. The web framework is three major versions behind, and the version in use no longer receives security fixes from its maintainers.
Impact: An upgrade is a cost the buyer inherits.
Unknown: The size of the upgrade. The sync job has no tests, which makes it harder to estimate.
Recommendation: An upgrade plan within the first 90 days, budgeted before signing.
Done when: A written estimate from the team, agreed by the buyer before signing.

Seller claims checked

Claim	Evidence found	Status
Real-time stock sync across branches	Runs once a night at 02:00; 30 runs in the September log	Contradicted
The business owns all its code	Repository and cloud account registered to a former contractor; no transfer agreement	Not verified
84 active customers	84 accounts marked active in the database; payments not checked	Partly verified
Daily backups of all customer data	Nightly backups, 14 kept; never restored	Partly verified
Hosting about USD 900 a month	Invoices of USD 1,140 to 1,260 a month	Contradicted
Two developers can maintain the product	Both write code; only the founder has released	Partly verified
Core features fully tested	210 tests; stock and billing covered, sync job not	Partly verified
Customer records stored in one database	Schema and row counts show one database	Verified

What is sound

The stock and billing logic is tested: 210 tests, all passing at the version reviewed.
The data model is clear. Each branch, product and stock movement has its own table, and the schema matches the architecture note.
The domain is registered to the business, and renews automatically.
The founder's written answers were complete and matched what the system showed, apart from the points above.

Conditions before signing, and the handover plan

First

Ownership of code, accounts and domains transferred at signing.
A witnessed restore of customer data.
The real-time claim corrected in the sale documents.

At signing: a written release procedure, and one release made from it by the part-time developer.
A handover period for the founder, agreed in the deal, with a weekly handover session.
All passwords and keys changed once the contractor's access is removed.

Later

First 90 days: an itemised bill, a decision on the idle server, and a framework upgrade plan.
Tests for the sync job, then a decision on whether to build real-time sync.

Open questions

Does the contractor's agreement give ownership of the code to the business? That is for the buyer's lawyers.
Do any customer contracts promise real-time sync?
Has there been any security incident or data loss in four years? The seller says no; there is no record either way.
Will the part-time developer stay after the deal?

Next steps

I walk you through the findings on a call, then answer one round of written questions. If you hire me for the first-90-days technical plan within 60 days, this review's full fee comes off its price.