Find Out What Actually Exists Before You Pay for It Again
Technical due diligence independently reviews an existing or half-built system - what works, code and data condition, security exposure, dependency on one person - for buyers, investors and owners deciding whether to continue, take over or walk away.
What Due Diligence Covers
This is for a system that already exists, in some form, and a decision that depends on knowing its real condition - continuing to fund it, acquiring it, taking it over from a departing developer, or walking away. We review what genuinely works against what was promised, the state of the code and its repository history, the integrity of the data, exposure to security risk, and how dependent the system is on any single person, then write the finding down without softening it.
When This Gets Called For
A Pharmacy Chain's App After the Contractor Went Quiet
A regional pharmacy chain's ordering app was built by a contractor who has since stopped responding, and nobody on staff can say what state the code, the database or the server configuration are actually in.
An Acquisition Where the Tech Is Part of the Price
A buyer is negotiating to acquire a business whose software is part of the valuation, and needs an independent view of the codebase's condition before the number is agreed, not after.
Instalments Going Out Against a Demo That Never Ships
Payments continue against a build that always looks nearly ready, and nobody on the paying side can open the code to check whether the work matches what has been invoiced.
What Gets Examined
- What is actually functional today, tested directly rather than taken from a demo or a status report
- The condition of the code and its repository history - structure, documentation, how it has been maintained
- Data integrity - whether records are complete, consistent and recoverable
- Security exposure - how access is controlled and where the obvious risks sit
- How dependent the system is on one person's knowledge, and what happens if that person is unavailable
What Drives Cost and Duration for a Diligence Review
The size of the codebase and how much of it has to be read directly rather than taken on the current owner's word, and whether access to the code, server and data can be granted quickly or has to be negotiated first. A system with cooperative access and a modest codebase reviews faster than one where access itself has to be fought for.
What You Hold at the End of the Review
A Plain Statement of What Exists
What is genuinely working, what is not, and what the gap between the two would cost to close - stated as found, not softened for either side of the transaction.
A Recommendation on the Decision at Hand
Continue, take over, renegotiate or walk away, argued from the evidence gathered, so the decision can be put to a board, a bank or a partner.
Frequently asked questions
Do you need cooperation from the current developer or vendor?
It helps but is not always available, and we can proceed without it if you can grant us direct access to the code repository, server and data. Where the current vendor is uncooperative, that itself is often a relevant finding.
Can this be done without the other party knowing?
Sometimes, if you already hold the access needed - your own server credentials, a code export - independently of the vendor. Where access depends on the vendor granting it, they will generally know a review is under way.
What if the finding is that the system is in worse shape than expected?
We write it as found. The value of an independent review is catching that before money changes hands or another instalment goes out, not producing a reassuring report regardless of what is actually there.
What drives the cost of a due diligence review?
The size of the codebase and how much of it needs direct reading versus relying on documentation, plus how many systems - code, server, database, third-party integrations - are in scope for the review.
What decides how long a due diligence review takes?
How quickly access is granted to the code, server and data. Where access has to be negotiated or is only partially available, that negotiation is usually the slower part, not the technical review itself.
Will you also tell us what it would cost to fix or complete the system?
Yes, where that is part of the brief - the review typically includes an estimate of what completing or repairing the system would involve, so the finding is actionable and not just diagnostic.
What do you need from us to start a due diligence review?
Access to the code repository, server and database wherever you can grant it, a clear statement of the decision this review needs to support, and, where relevant, whatever documentation or contracts exist for the original build.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private