Technical due diligence: 122 of 125 database tables empty

A buyer asked us to review a workforce-management platform before signing. It was presented as 220,000 lines of code, 253 pages and 164 API endpoints. Our technical due diligence found mostly a user-interface shell: 122 of its 125 database tables were empty, access control existed only in the browser, and much of the business logic a staffing platform depends on had not been written. The buyer had a written report, in DOCX and HTML, before the decision.

This case study explains how we reached that conclusion, what the numbers meant, and what any buyer of software should ask for before committing money. The buyer, the seller and the product stay confidential.

What is technical due diligence?

Technical due diligence is an independent review of a software product before someone buys it, invests in it or signs a large contract for it. It compares what the seller says against what the code, the database and the running system show, and it ends in a written report of risks ranked by severity, with the cost of fixing them.

It is not a code-quality score. The question it answers is a buyer's question: does this software do what I am being told it does, and what will it cost me to make it do so? A system can have tidy code and still be empty, or messy code and still carry a working business.

What were we told the platform was?

The platform was described as an AI-powered workforce-management system covering vendor management, applicant tracking and project management, positioned against large enterprise products. The headline figures were volume figures: about 220,000 lines of code, 253 pages and 164 API endpoints, supported by 334 documentation files.

Volume figures are easy to produce and easy to believe. They say how much was written, not what it does. Our job was to turn each claim into something we could check.

Documentation is a claim too, not evidence. A large body of it can look like a sign of maturity, but documents describe what was planned or intended, not necessarily what was built. So every feature the documentation described was checked the same way as the sales material: we looked for it in the code, in the database and in the tests. Where the documents disagreed with each other, we recorded both versions and let the repository decide.

How we checked: claims, repository, running system

Our method has three layers, and each claim has to survive all three. First we list the claims exactly as made. Then we check each one against the repository and the database. Finally we check it against the running system, the way a real user would meet it. A claim that fails an earlier layer is settled there.

A UI shell is a front end that renders screens convincingly but is not connected to working business logic or real data behind them. It is what you get when screens are built first and the system underneath is postponed.

For this platform the gap was visible at the second layer:

• The database. The schema defined 125 tables. 122 of them had no rows. Only 6 tables held any data, 286 records in total. Within that data there were 21 duplicate document numbers, and 22 tables had no primary key.
• The endpoints. The 164 API endpoints existed as route definitions, but many returned mock or hard-coded data, which the project's own documentation acknowledged.
• The business rules. For a staffing platform, the value is in rates, margins, billing and compliance. The documented business logic came to six formulas, five of them basic arithmetic. Margin calculation and payment processing were not there.
• Completion. The project's own documents gave completion figures from 71% to 100% for the same product, depending on which document you read.

What did the security review find?

Access control was enforced only in the browser. The project's own documents listed server-side authorisation as pending, which means any user who called the API directly could bypass the role checks. A default administrator password appeared in plain text across several documentation files and test scripts, and the production security checklist was unchecked.

Server-side authorisation means the server itself checks, on every request, whether this user may do this action. Checks that live only in browser code can be skipped by anyone who sends requests directly. OWASP ranks broken access control as the first risk in its Top 10.

None of this is unusual in a prototype. It becomes a problem when a prototype is priced and sold as a platform.

What did the buyer receive?

The buyer received a written report in two formats: a DOCX file for their advisers and an HTML version for reading on screen. It separated what existed and was worth keeping from what did not exist, listed each claim next to the evidence, and ranked the gaps by the risk they posed to the purchase.

The report left the decision with the buyer and showed exactly what they would be buying. The parts worth keeping were named plainly: a real schema to build on, working create-read-update-delete screens for the core records, a voice-agent integration that was one of the more complete features, and a handful of sound architecture decision records.

The value of the review was its timing. Found after signing, the same facts would have become a dispute. Found before, they became a negotiating position.

What should buyers ask for before signing?

Ask for access, not assurances. A seller confident in their software can give you read access to the repository, the database schema with row counts, a running environment and the test results. If they cannot, that is a finding in itself. These requests cost the seller nothing if the product is what they say it is.

1. Repository access with full history. Not a zip file. History shows who built what, when, and whether it has been maintained.
2. Database schema with row counts per table. Empty tables mark features that exist on screen only.
3. A normal user account on a running environment. Not a scripted demo; your own clicks, on your own paths.
4. The test suite and its latest results. No tests means nobody has proved the business rules work.
5. Where authorisation is enforced. Ask to see the server-side check for one sensitive action.
6. Every external service and credential. Who holds the keys, and what it costs to run.

Treat lines of code, page counts and endpoint counts as descriptions of size, not of value. The question is always what the system does with real data, and whether it does it safely.

Get an independent review before you sign

We run technical due diligence from €2,500 and code reviews and security audits from €1,500, each with a fixed price agreed in writing and a written report ranked by risk. How we approach reviews and audits is described under code reviews, audits and due diligence. To discuss a purchase or an investment, book a free 30-minute call.