The technology is usually the thing you are actually buying, and it gets the least scrutiny. The financials get taken apart line by line. The platform gets a demo and a few reassuring chats. That gap is where the nasty surprises live: the product that can’t scale, the debt that eats the roadmap, the “AI” that turns out to be people typing fast, the team that walks once the founders cash out.
So here is what investors miss most, what a real diligence examines, a worked example of how one finding changes a price, and where the exercise goes wrong.
The five things investors miss most
It’s rarely the obvious stuff. In our experience it is these five, and each has a simple tell.
- Scalability reality. A product that runs fine for today’s users may need a serious rebuild to handle the growth your valuation assumes, and the model almost never budgets for it. Ask for today’s peak load and what breaks at ten times that. If nobody can answer, that is the answer.
- Technical debt. Under deadline pressure, shortcuts pile up, and heavy debt makes every future feature slow and expensive, throttling the growth you’re paying for. The tell is velocity: how long a small change takes now versus a year ago.
- Key-person dependency. When the whole system lives in two founders’ heads, you’re buying knowledge that can walk out the door. Read the commit history and ask for the architecture document. Two authors and no document means you are buying two people, not a platform.
- Story versus substance. “AI-powered.” “Fully automated.” “Enterprise-ready.” Diligence is where you find out if those words are architecture or aspiration. Ask to see the model, the training data, and the monthly inference bill. A rules engine with an operations team behind it is a cost structure, not a moat.
- Security and compliance exposure. Weak security or PDPL gaps don’t stay the seller’s problem. You inherit them, and they surface after closing, with your name on the breach notification.
The one question every finding has to answer
Good diligence grades four areas at once, honestly. Picture a map: solid ground here, soft ground there, and one bridge that has to hold, between the technology and the business case you’re buying.
flowchart TD
A(["Architecture and scalability"]) --> F{"Can the tech deliver the business case?"}
B(["Code and technical debt"]) --> F
C(["Team and key-person risk"]) --> F
D(["Security and compliance"]) --> F
F -->|Yes| G(["Back it, with eyes open"])
F -->|No| H(["Reprice, restructure, or walk"])
Each box gets a verdict: what’s solid, what’s concerning, what it costs to fix, and how that shapes the deal. The output isn’t a thumbs up or down. It’s a priced, dated list of risks an investment committee can act on. A finding without a cost and a date is an observation, not diligence.
What a real diligence actually examines
The demo tells you what the product does on a good day. These tell you what it does on a bad one. We keep a fuller technical due diligence checklist for Saudi VCs and PE; this is the short version.
- An architecture walkthrough, not a deck. A whiteboard session with the lead engineer: the system diagram, where the data flows, where the single points of failure sit.
- Read access to the repository, the CI pipeline, and the cloud bill. Test coverage, how a release reaches production, how long a rollback takes, and hosting cost per customer, the unit economics the pitch skipped. The red flags an engineer looks for in a startup’s codebase show up in an afternoon.
- A dependency and licence audit. Open-source licences that restrict a product you plan to sell, abandoned libraries, unpatched vulnerabilities.
- The team map. Who owns which system, who leaves when the earn-out ends, and what the retention terms actually say. Assessing the tech team before you fund or acquire is half the exercise: you’re buying the builders, not just the build.
- Security evidence, not assurances. The last penetration test report, the incident log, and who has production access. If the target sells to government or critical sectors, ask how far it is from NCA’s ECC controls.
- Data and PDPL. Where personal data physically lives, whether it crosses borders, and whether the record of processing exists at all. SDAIA is the regulator, and a target that cannot show you the record hasn’t started.
- Where the revenue really comes from. If the contracts came through Etimad, read the technical obligations and renewal dates. If the target is a fintech, SAMA’s Regulatory Sandbox and a full licence are different things to buy.
flowchart LR A(["Week 1: documents and access"]) --> B(["Week 2: architecture and code"]) B --> C(["Week 3: team, security, data"]) C --> D(["Week 4: priced, dated findings"]) D --> E(["Deal terms: price, escrow, conditions"])
Why the numbers say look harder
Across roughly 40,000 deals over 40 years, about 70 to 75% of M&A deals fail to create value (Fortune, 2024). Technology integration is among the top causes, inadequate due diligence is cited in around 31% of failures, and middle-market deals often allow only 30 to 45 days when 60 to 90 is advisable. A lot of that fate is sealed before anyone signs.
IBM’s 2024 study put the average cost of a data breach in the Middle East (a Saudi and UAE sample) at $8.75M, the second-highest region after the US, against a global average of $4.88M (IBM via The National, 2024). Once you own the company, that is your exposure, not the seller’s.
A worked example: what one finding does to the price
The numbers here are made up to show the shape. Say you’re buying a majority stake in a logistics SaaS business at SAR 60 million, and the case assumes five times today’s customers within three years.
Diligence finds three things. The platform runs on a single database with no replication, so the growth case means rebuilding the data layer: call it four engineers for nine months. The routing engine, the actual product, was written by one engineer with no retention terms. And there is no PDPL record of processing, and customer data sits outside the Kingdom with no transfer basis.
Priced honestly, say the rebuild is SAR 4 million, the retention package SAR 1 million, the PDPL and data-residency work SAR 1 million, and the growth curve slips by a year. That is SAR 6 million and twelve months against a SAR 60 million price. None of it is a reason to walk. All of it is a reason to change the deal: a price adjustment, a holdback until the data layer ships, retention terms as a closing condition, and the PDPL work as a day-one obligation with a named owner. Three technical facts became four deal terms. That’s the whole job.
Where technical due diligence goes wrong
The exercise fails in predictable ways, and most of them are false economies.
- The founder-led demo. The founder drives, the happy path works, everyone nods. Insist on the walkthrough and the repository, and let your reviewer choose what to click.
- The 30-day squeeze. Technical review gets the days left over after the financial and legal work, so it shrinks to a questionnaire, answered by the seller’s most optimistic person.
- Grading by the target’s own advisor. The firm that built the platform, or resells the cloud it runs on, is not an independent reviewer. Ask who is paid by whom first.
- A checklist with no verdict. Two hundred findings, none priced, none ranked. The committee can’t act on it, so it becomes an appendix.
- Security as a scan. An automated scan is not a penetration test, and a certificate on the wall is not a control. Read the incident log.
- Diligence that stops at signing. Value is lost in integration, not at closing. If the report doesn’t become the first hundred days’ plan, what you learned evaporates.
How to start
The pattern that works is boring and reliable. Write the business case in one paragraph and underline what the technology has to do for it to hold. Before engaging anyone, ask the target for four things: the architecture diagram, read access to the repository, the last penetration test report, and the PDPL record of processing. What arrives, and how fast, is your first finding.
Then scope the review to the questions the business case depends on, insist that every finding comes back priced and dated, and turn the list into deal terms before the committee meets. After closing, the report becomes the integration plan. Done that way, an independent technology assessment and due diligence pays for itself on the first repriced finding.
Committing capital to a technology business? SDCG runs independent technical due diligence. Architecture, code, team, security, and the gap between story and substance, so you know exactly what you’re backing before you sign. We don’t resell the technology and we don’t take a finder’s fee on the deal, so the only thing we’re grading is the risk. Book a free 30-minute review.