You can tell whether a startup’s codebase is a risk long before you have read every line of it, because the signals that matter show up on the first day of a technical due diligence. This post lays out those signals in four buckets, shows how to turn the ones you find into a number, and explains why the fourth bucket, the one about the team rather than the code, decides more deals than the other three combined.
Around 70-75% of M&A deals fail to create value, and inadequate due diligence is cited in roughly 31% of those failures (Fortune, 2024). The red flags below don’t kill a deal on their own. Each one tells you where to look harder and what to price before you commit.
flowchart TD
A(["Architecture and code"]) --> E(["How worried should you be?"])
B(["Process and practice"]) --> E
C(["Security and compliance"]) --> E
D(["How the team responds to scrutiny"]) --> E
E --> F{"Honest with a plan, or defensive?"}
F -->|Honest| G(["Price the risk, proceed"])
F -->|Defensive| H(["The bigger red flag. Dig in"])
Architecture and code: where the bones show
You need the architecture diagram (or the absence of one), the dependency list, and an hour with the person who wrote most of it.
- No one can explain how it works. Ask the lead engineer to draw the system on a whiteboard in ten minutes. If they can’t, the design is a tangle or the knowledge lives in one or two heads. Both are risks.
- Everything is entangled. When a change to billing can break login, every feature carries a hidden cost. If small pull requests touch dozens of files and take days to land, the coupling is already taxing the team.
- Debt that is acknowledged but never touched. Some debt is normal. A backlog that has been “next quarter” for two years means the work you are paying for will be slow and expensive exactly when the growth plan needs it fast.
- No meaningful tests. Zero automated tests, or tests switched off in the pipeline, means every release is a gamble. The tell is not a coverage percentage. It is whether the team can ship on a Thursday afternoon without fear.
Process and practice: how they ship tells you how they think
Code can be refactored. Habits are harder. This bucket is cheap to assess: it is all in the git history and the deployment tooling.
- No version control discipline or real deployment process. Direct commits to the main branch, releases done by hand from someone’s laptop, no rollback path. Chaos here predicts chaos everywhere.
- No documentation of critical systems. No README that works, no runbook for the 3am outage, no record of why the big decisions were made. It raises key-person risk and slows every handover, including the one to you.
- Manual work dressed up as automation. “Automated” onboarding or “AI-powered” matching that is really a person behind the scenes works at a few dozen customers and breaks at a few hundred, and the business case assumes it scales.
- A bus factor of one. Run
git shortlogon the last year of commits. If most of them belong to one person, the codebase and that person’s employment contract are the same asset.
Security and compliance: the liabilities you inherit
Here a red flag stops being a slowdown and becomes a cheque. The global average cost of a data breach hit a record $4.88M in 2024, and the Middle East sample (Saudi Arabia and the UAE) averaged $8.75M, the second-highest region after the US (IBM via The National, 2024). The target’s security posture on closing day is yours the day after.
- Secrets in the code, no access control, no security habit. API keys in the repository, one shared admin password, former staff with live credentials. It signals an immediate hole and a culture that treats security as someone else’s job.
- Personal data handled with no regard for PDPL. The Personal Data Protection Law took effect on 14 Sept 2023, full compliance was required by 14 Sept 2024, and SDAIA is the regulator (Morgan Lewis, 2024). A startup that cannot tell you what personal data it holds, where it is stored, or whether any of it leaves the Kingdom is handing you a compliance debt. Our practical guide to PDPL compliance covers what compliant looks like inside a system.
- Sector rules ignored. If the target sells to a bank, NCA ECC controls and SAMA’s expectations bind its customers, so they bind it too. Sell to hospitals and the same is true of NPHIES integration. Ask which frameworks its customers have audited it against.
The meta-signal: how the team responds to scrutiny
This is the one. A strong team is honest about its debt and its risks. They know where the bodies are buried and have a plan for the order they would fix things in. A team that gets defensive, vague, or dismissive about real concerns is a bigger red flag than any single technical issue, because it tells you what the next three years of working with them will feel like.
In our experience, one question does more than any code review: “If money were no object, what would you fix first?” A good engineer answers instantly and in detail. A worried one changes the subject. Ask it separately of the CTO and the most senior engineer: if the answers match, the team knows its system; if they don’t, someone is managing the message. Pair this with our guide to assessing a tech team before you fund or acquire, because the team is the asset the code depends on.
A worked example: pricing a red flag
Say you are acquiring a Riyadh SaaS startup with 12 engineers and 300 business customers, and the review finds three things: no automated tests on the billing service, credentials committed to the repository, and no register of what personal data the system holds. The numbers below are made up to show the shape.
- Tests on billing. Two engineers for three months, so six engineer-months. At an illustrative all-in cost of SAR 30,000 per engineer-month, that is SAR 180,000, plus the features those two people are not building.
- Secrets clean-up. Rotating every credential, moving them into a proper vault, and auditing who used them. Two weeks for one senior engineer, call it SAR 20,000, plus an external penetration test at SAR 60,000.
- PDPL data register and remediation. A month of one engineer and a compliance lead to map the data, fix consent and retention, and document any cross-border flows. Say SAR 80,000.
That is roughly SAR 340,000 of remediation before the product can grow safely, in a deal priced as if the platform were ready to scale. None of it kills the deal. It gives you three options: a price adjustment, an escrow tied to the remediation plan, or a closing condition that the secrets are rotated before signature. Without the review, you have none of them.
Where a codebase review goes wrong
- Treating it as a code quality contest. You are not grading elegance. You are pricing risk. Ugly code that ships reliably and is understood by five people beats beautiful code understood by one.
- Letting the target run the tour. A guided demo is not a review. Ask for repository access, read-only production monitoring, and the last six months of incidents.
- Reading only the code. Half the risk sits outside the repository: who owns the cloud account and the domain, and which third-party services the product cannot run without.
- Running out of time. Middle-market deals often allow only 30-45 days for diligence when 60-90 is advisable (Fortune, 2024). A review squeezed into the last week produces observations, not a priced risk.
- Treating every flag as fatal. Almost every startup has some of them. The question is whether the team knows, whether it has a plan, and whether the price reflects it.
How to start: the two-week version
The reliable pattern is boring: pick the one system the revenue depends on, check the four buckets against it, then price what you find.
flowchart LR A(["Days 1-2: the signals and the one question"]) --> B(["Week 1: the revenue-critical system in depth"]) B --> C(["Week 2: security, PDPL, dependencies"]) C --> D(["Price each finding"]) D --> E(["Decide: adjust, escrow, or condition"])
Go deep on the one system the customers pay for, not the whole estate, and put a number and a fix-order next to every finding. Our technical due diligence checklist for Saudi VCs and PE is the list we start from, and our technology assessment and due diligence service is the version of this we run for investors and acquirers.
Need to know what’s really in the codebase before you invest or acquire? SDCG runs independent codebase and engineering assessments, then translates them into plain business-level risk. What’s solid, what’s concerning, and what it’ll cost to fix. We’re independent, so we’re not pitching a rebuild we’d love to sell you. Book a free 30-minute review.