Most deals fail, and technical diligence is the part investors skip. An analysis of roughly 40,000 mergers and acquisitions over 40 years found that 70 to 75% fail to create value, and inadequate due diligence is named in about 31% of those failures (Fortune, 2024). The financial side usually gets done properly; the technical side is where corners get cut and the expensive surprises hide. Here is the checklist we use: five areas, in order, the questions that actually tell you something, and what to do with the answers. It is calibrated for the Kingdom, where PDPL, SAMA and NCA obligations transfer with the deal whether you priced them or not.
Picture five lenses pointed at the same company, each at a different layer, all feeding the same verdict.
flowchart LR A(["1. Technology and architecture"]) --> E(["5. The business-case bridge"]) B(["2. Engineering practice"]) --> E C(["3. Team and key-person risk"]) --> E D(["4. Security and compliance: PDPL, SAMA, NCA"]) --> E E --> F(["A priced risk map, not a pass or fail"])
1. Technology and architecture: is it what they say it is
Start here; everything else sits on top of it. The question is whether the thing in the deck is the thing in production, and whether it can carry the plan.
- Ask for the architecture drawing, then ask why. A team that built it deliberately can explain every box and the trade-off behind it; one that cannot usually inherited it or grew it by accident.
- Test the scaling claim against the model. If the business case assumes ten times the transactions, ask what breaks first: the database, the queue, a third-party rate limit. “It’s on the cloud, it scales” is not an answer.
- Price the technical debt, do not just note it. What does it cost to carry for two more years versus fix, in engineer-months? That number belongs in your model.
- Check the “AI-powered” claim in person. Plenty of fully automated products have people quietly doing the work behind the curtain. Ask to watch a live case handled with no human touching it.
Our guide to red flags in a startup’s codebase covers what an engineer can spot in an afternoon.
2. Engineering practice: heroics or a process
Can the company keep shipping after you invest, or does it run on a few people’s late nights?
- Version control and review. One repository, a full history, review before merge. If production code lives on a laptop, stop and note it.
- Automated tests that actually run. Not “we have tests.” Ask to see last week’s pipeline runs.
- A deployment you could watch. Ask to see a release go out. If it depends on one person’s memory, releases stop when that person is on leave.
- Documentation for the critical paths. Payments, authentication, the data model. If those live in two people’s heads, the knowledge walks out when they do.
Calibrate to stage: a seed team gets a pass on things a Series B team should not.
3. Team and key-person risk
In a technology deal you are buying the people as much as the product. We wrote a fuller guide to assessing a tech team before you fund or acquire; the short version is four questions.
- Who actually wrote the core? The commit history tells you. If most of the important code came from one person, or an agency that has since left, the team you are meeting is not the team that built it.
- What is the bus factor? Name the two people whose departure would stop the product, then ask what is being done about it today, not after the round.
- What keeps them after close? Vesting, incentives, a real say in the next chapter. In our experience the founders’ technical lieutenants leave more often than the founders do.
- Who leads the next stage? A brilliant founding engineer is not automatically a CTO for a hundred-person company, and “we’ll hire one” quietly makes that role your problem. An interim CTO for the first year after close is a sensible term.
4. Security and compliance, sharpened for the Kingdom
The Kingdom raises the bar here, and a breach is expensive: IBM’s 2024 study found the Middle East (a Saudi and UAE sample) averaged $8.75M per breach, the second-highest region after the US, against a global average of $4.88M (IBM via The National, 2024).
- PDPL, specifically. Full compliance was required by 14 September 2024, with SDAIA as the regulator (Morgan Lewis, 2024), so a target that is “working on it” is already late. Ask for the record of processing activities, the consent flow, the retention rule, and how cross-border transfers are handled under Article 29.
- Sector regulators. SAMA for fintech, including whether the company is still inside the Regulatory Sandbox. NCA’s Essential Cybersecurity Controls where the target serves government or critical sectors. NPHIES connectivity for anything touching health data.
- Security basics, evidenced. The latest penetration test and what was fixed, how secrets are managed, who has production access, and the incident log.
- Inherited liabilities. IP assignment from every contractor who touched the code. Open-source licences that could force disclosure. Third-party services the product cannot run without.
5. The business-case bridge
This is the lens investors skip, and the one that matters most. The first four produce findings; this one converts them into price, terms, and plan.
- Capacity against the plan. Does the system support the growth, margins, and timeline the investment assumes? If not, the rebuild is a use of proceeds and belongs in the model.
- The technology spend that is not in the model. Security remediation, compliance work, closing the key-person gap, the debt you priced in lens one. Add it up.
- The top three risks, each with a likelihood and a cost, and a view on how each should move valuation or terms.
A worked example, with the numbers made up to show the shape. Say you are pricing a Series A in a Saudi fintech, and the model assumes transaction volume grows ten times in 24 months. Diligence finds a single-database monolith that will strain at around three times today’s load. The team estimates a nine-month re-architecture at roughly 4 million riyals, and the two engineers who understand the payments core are on vesting that ends in a year. None of that kills the deal, but it does mean the 4 million comes out of the pre-money or goes in as a ring-fenced use of proceeds, the growth curve slips two quarters, and retention packages for those two engineers become a closing condition. That is a bridge: findings turned into terms.
Where technical diligence goes wrong
The failures we see are about process, not technical detail.
- Trusting the deck. The architecture slide is a marketing document. Diligence happens in the repository, the pipeline, and the cloud console, or it did not happen.
- Running out of time. Middle-market deals often allow only 30 to 45 days when 60 to 90 is advisable (Fortune, 2024). It is usually the last workstream to start and the first cut short. Start it in week one.
- Using an assessor who wants the next contract. If the firm reviewing the code would also like to rebuild it, the risk map tilts toward a rebuild. Independence is not a nicety here; it is the product.
- Treating compliance as legal’s problem. Lawyers can judge the privacy policy. They cannot tell you whether the system actually deletes data when it says it does. That is an engineering check.
How to run one without slowing the deal
The reliable pattern is boring. Scope it in one day: which lenses matter most for this deal, and what the business case depends on. Give it two to three weeks of real work, with access to the repository, the pipeline, the cloud accounts, and the engineers, not just the founder. Deliver one document: a risk map that says what is solid, what is worrying, and what each item costs to fix. Then run every finding through the same gate.
flowchart TD
A(["A finding on the risk map"]) --> B{"Fixable before close?"}
B -->|Yes| C(["Closing condition"])
B -->|No| D{"Can you price it?"}
D -->|Yes| E(["Adjust valuation or terms"])
D -->|No| F{"Does it break the plan?"}
F -->|No| G(["Accept, into the 100-day plan"])
F -->|Yes| H(["Walk away"])
The map, not a pass or fail, shapes your price, your terms, and your post-investment plan. If you would rather not build that muscle for a few deals a year, that is what an independent technology assessment and due diligence engagement is for. The whole point is simple: no surprises after you have signed.
Want diligence that leaves no technical surprises? SDCG runs independent technical due diligence for investors across the Kingdom: architecture, code, team, security, and PDPL and sector compliance, delivered as a priced risk map you can act on. We don’t resell anything and we’re not chasing the rebuild, so the read you get is the honest one. Book a free 30-minute review.