Technical due diligence checks that the product works as claimed, truly belongs to the seller and can be taken over without excessive risk. It covers code, infrastructure, security, data, dependencies and key people. It must happen before signing, not after.
Code and architecture: is the product maintainable?
Examine the code structure, the presence of tests, version control and documentation. The goal is not perfection but to gauge the effort needed to evolve the product.
Also ask who wrote the code and under what conditions: employees, freelancers or an agency. This determines intellectual property.
- A complete code repository with a readable history
- Automated tests and a documented deployment process
- Known technical debt acknowledged by the seller
- Signed rights assignments from every contributor
Infrastructure, security and data
Check where the product is hosted and who owns the cloud accounts, domain names and certificates. A transfer should be clean, with no hidden access.
On security and data, look at access management, tested backups, encryption and compliance with Moroccan personal data law, or European rules if customers are based there.
Dependencies, costs and third-party risk
List third-party services: payments, messaging, artificial intelligence, maps. Identify the critical ones, their terms of use and the costs that rise with usage.
Review open source licences: some impose obligations that can get in the way of a resale or a commercial model.
- An inventory of third-party services and related contracts
- Open source licences compatible with the business model
- Infrastructure costs compared with real usage
- A fallback plan if a key supplier fails
Team, knowledge and transition plan
Identify the people without whom the product stops running. If knowledge sits with one person, plan their retention or a structured handover before closing.
Finish with a transition plan: access, documentation, handover sessions, a support period. The purchase price should reflect the risks found, possibly with contractual guarantees negotiated with legal counsel.
Frequently asked questions
How long does technical due diligence take?
It depends on the size and complexity of the product. For a small SaaS it can fit into a few days of focused work, but it is better not to rush it.
Do I need an external expert to audit it?
If you lack in-house technical skills, it is strongly advised. An independent view avoids relying only on the seller's statements.
What if the audit reveals problems?
Assess their severity and cost to fix, then renegotiate the price, ask for guarantees or require a fix before closing. In some cases, walking away is the right call.