A pitch deck can promise a scalable platform, proprietary technology and a world-class team. The codebase tells you whether that is true. Technical due diligence doesn’t need to be a months-long exercise, and you don’t need to read code yourself. You need the right questions and an independent reviewer who can answer them in plain language before you commit capital.
Start with ownership and IP
The first question isn’t technical at all. Does the company actually own its code? Check that every founder, employee, freelancer and agency who contributed has signed an IP assignment to the company. We have seen early products built by an outside agency on a contract that never transferred ownership, which becomes a serious problem at a funding round or exit.
Then look at what the product is built on. Open-source libraries are normal and healthy, but some licences, such as AGPL, can create obligations for commercial products. A reviewer can scan the dependencies in a day and flag anything that needs a lawyer’s attention. Also confirm that cloud, app store and domain accounts are owned by the company, not a founder personally.
Check dependence on outside platforms as well. A product built entirely on one marketplace’s API, one no-code tool or one AI provider can be disrupted overnight by a pricing change or a policy update. That doesn’t rule out an investment, but you should understand how hard it would be to switch and whether the team has a plan for it.
Security and data protection
A breach after you invest is your problem too. In the region, the UAE’s Personal Data Protection Law and Saudi Arabia’s PDPL both set real obligations around consent, storage and cross-border transfers, and sectors like fintech and health have their own regulators on top. Ask where customer data is stored, who can access it and how that is controlled.
- Secrets in code — passwords or API keys committed to the repository are a common and serious finding.
- Access control — whether former staff still have production access, and whether two-factor authentication is enforced.
- Card data — whether payments go through a compliant gateway, or card numbers touch the startup’s own servers.
- Backups — whether they exist, are stored separately, and have ever actually been restored.
Ask, too, whether the company has ever had a penetration test, and what happened to the findings. A recent test with issues fixed is reassuring; a report sitting unread in a folder is not. Ask directly about past security incidents and how they were handled. An honest answer about a past problem is often a better sign than a claim that nothing has ever gone wrong.
Don’t ask whether the code is perfect. Ask whether the team knows exactly where it isn’t.
Architecture, scale and technical debt
Every startup has technical debt; that is the price of moving fast. What matters is whether it is understood and manageable. Can the current system handle the growth in the business plan, perhaps ten times today’s users, without a full rebuild? If a rewrite is needed soon after the round, that cost and delay belong in your valuation conversation.
Look at hosting costs as a share of revenue too. A product that spends unusually heavily on cloud or AI model calls per customer may have a margin problem disguised as a technical one. A good reviewer will compare the bill with usage and tell you whether it should fall as the product scales, or keep climbing alongside it.
Be especially curious about claims of proprietary AI. Many products described as having their own AI are a well-designed layer on top of a third-party model. That can be a perfectly good business, but the defensibility then lies in data, workflow and distribution, not the model. A reviewer can tell you quickly which one you are looking at.
The team and how it ships
Code is only as durable as the people and processes around it. Ask how many people understand each critical part of the system. If one engineer, often a technical co-founder, is the only person who can deploy or fix the payment flow, that is a key-person risk worth addressing with documentation and hiring as part of the deal.
Healthy teams release small changes often, with automated tests and a deployment pipeline, and they can tell you how long it takes to recover from an outage. Teams that deploy rarely, by hand, at night, are usually carrying fragility that will slow the growth you are paying for. The table below summarises what we flag most often.
You don’t need to judge code style, but the basics are revealing. Is every change reviewed by a second engineer? Is the code readable to someone new, with sensible structure and naming? Could a new hire ship a small fix in their first week? These are simple questions a reviewer can answer, and they predict how fast the team can grow after the round.
How to run the review
A good technical review is collaborative, not adversarial. Founders who understand that it protects them too usually share access readily. In our experience, the process looks like this for a seed or Series A company, and the cost typically ranges from about USD 5,000 to 20,000 depending on the size of the system:
- Agree scope and confidentiality, then get read-only access to the code, cloud console and issue tracker.
- Interview the technical lead and one or two engineers about architecture, history and known weaknesses.
- Run automated scans for dependencies, licences, secrets and common vulnerabilities.
- Receive a written report with findings ranked by severity, likely cost to fix and suggested deal conditions.
The bottom line
You wouldn’t invest without checking the accounts, and the code deserves the same care. Use an independent reviewer with no stake in the deal, ask for a plain-English report with risks ranked by severity and cost, and treat findings as negotiation points rather than deal-breakers. Most issues are fixable; the dangerous ones are those nobody mentioned.
