Technical due diligence
Technical due diligence on software you are about to buy
A seller demo shows you the product working. It tells you nothing about whether the thing underneath can be maintained, scaled or staffed after you own it. We read the actual codebase, the deployment path and the dependency surface, and report what we find in language a deal team can act on. We are not competing for the remediation work, so there is no incentive to make it sound worse than it is.
What you are buying, before the money moves
Codebase and architecture
What the system is actually built from, how the pieces depend on each other, and where the structure will resist the roadmap you are buying it for. Measured, not eyeballed: test coverage, dependency age, duplication, dead surface area.
Key-person and process risk
Whether anyone other than the current team can deploy, restore and extend this. Undocumented deploys, a build only one laptop can run and credentials in one person head are valuation risks, and they are common.
Security and licence exposure
Exposed services, unpatched dependencies with known advisories, secrets committed to history, and open-source licences that are incompatible with how the product is sold. Any of these can become the buyer problem on day one.
Cost to put right
Each finding carries an estimate in effort and sequence. The output is not a list of complaints, it is the first six months of an engineering plan, with the items that should affect the price marked as such.
You probably need this if…
- You are acquiring a company whose product is its main asset
- An investment committee is asking technical questions nobody can answer
- A vendor quote or a roadmap looks optimistic and you cannot tell why
- You inherited a system in a deal that has already closed
What you get
- A written report ranked by impact on the deal, not by technical severity
- An executive summary a non-technical deal team can read
- Remediation estimates in effort and sequence
- A findings walkthrough with your team or the target team
- A follow-up read after remediation, if the deal structure needs one
Everything we produce is yours, including the discovery document - whether or not the build goes ahead.
Technical due diligence: common questions
How much access do you need, and how long does it take?
Read access to the repositories, the deployment configuration and the dependency manifests covers most of it, plus an hour with whoever maintains the system. Most reviews run one to three weeks depending on size. We work under NDA as a matter of course.
Will you recommend rebuilding everything?
Almost never, and we are not positioned to benefit from it. A rebuild is the most expensive answer to most problems and usually the wrong one. The report says what is sound as clearly as it says what is not, because overstating risk costs you a deal that was fine.
Due diligence: tell us what you need
Send a short description of the problem. You will get a straight answer on whether this is the right fit and what it would take.
A reply from a developer. Not a sales pipeline. The person who reads your message is the person who would do the work.
An honest answer on fit. If an off-the-shelf product solves your problem better than a custom build, we will tell you which one.
No obligation. A first conversation costs nothing and commits you to nothing. Discovery output is yours either way.