Investor Tech Due-Diligence Checklist

Can the system carry the growth in your plan?

1. 1.Can you draw the system on one page and explain why it is built this way?What good looks like: A current architecture diagram, and someone who can explain each major choice and its trade-off.
2. 2.What breaks first if usage grows ten times?What good looks like: You know the bottleneck (database, a third-party API, a background job) and have a plan and a rough cost to fix it.
3. 3.Where are the single points of failure?What good looks like: Critical services, data stores and people are listed, each with a fallback or recovery plan.
4. 4.How much of the product depends on platforms you don't control?What good looks like: Key vendors are listed, with what happens if one raises prices, rate-limits you or goes down.
5. 5.Can a new engineer run the product locally and ship a change in their first week?What good looks like: Documented setup, a staging environment and a short onboarding guide that someone has actually followed.

Can the team change the product safely and quickly?

1. 6.How are changes reviewed before they reach production?What good looks like: Every change goes through a pull request with review and automated checks; nobody pushes straight to production.
2. 7.What is tested automatically, and what isn't?What good looks like: Tests cover the paths that make or lose money (sign-up, payments, the core workflow), run on every change, and the gaps are known.
3. 8.How often do you release, and how often does a release cause an incident?What good looks like: Small, regular releases, with a simple record of incidents and rollbacks you can show.
4. 9.How much technical debt is there, and is it written down?What good looks like: A short, prioritised list of known debt with rough effort, not a vague sense that the code is messy.
5. 10.How much of the code was AI-generated, and who has reviewed it?What good looks like: The team knows where AI-generated code lives, and a human has reviewed the security-critical parts.

Is customer data safe, and do you know which rules apply to it?

1. 11.Where are secrets such as API keys and database passwords kept, and who can see them?What good looks like: In a secrets manager or environment config, never in the code, the browser bundle or git history, and rotated when people leave.
2. 12.How is access to customer data controlled?What good looks like: Rules enforced on the server or in the database (for example row-level security), tested as a second user, with least-privilege admin access.
3. 13.What personal data do you hold, where is it stored, and which laws apply to it?What good looks like: A simple data map (what, where, why, for how long) and a view, confirmed with a lawyer, of which regimes apply, such as the UAE PDPL or the EU GDPR.
4. 14.Has anyone outside the team tested your security?What good looks like: An independent review or penetration test that fits your stage, with the findings tracked until closed.
5. 15.What happens if you are breached?What good looks like: A written incident plan: who decides, who is told, how keys are rotated and how customers are informed.

Will it stay up, and will the bill scale sensibly?

1. 16.Are backups automatic, and when did you last test a restore?What good looks like: Automated backups, and a restore that has actually been tested, with a known recovery time.
2. 17.How do you know the product is down before customers tell you?What good looks like: Error tracking, uptime monitoring and alerts that reach a named person.
3. 18.How do you deploy, and how do you roll back a bad release?What good looks like: Automated, repeatable deploys, and a rollback that more than one person knows how to run.
4. 19.What does infrastructure cost each month, and how will that grow with customers?What good looks like: You know the monthly bill, what drives it, and roughly the cost per customer or per transaction.
5. 20.Are production, staging and development kept separate?What good looks like: Separate environments and data, and no testing on real customers' data.

Can this team deliver the roadmap the money is paying for?

1. 21.If your lead engineer left tomorrow, what would stop working?What good looks like: Knowledge is written down and shared, and access and credentials don't depend on one person.
2. 22.Who makes technical decisions, and how are they recorded?What good looks like: A named technical owner, and short written records of the major decisions and why they were made.
3. 23.How is work planned, prioritised and tracked?What good looks like: A visible backlog, a regular planning rhythm, and a clear line from the roadmap to what engineers are doing this week.
4. 24.How do you work with agencies or contractors?What good looks like: Clear contracts and deliverables, code in your own repositories, and someone on your side able to judge the work.
5. 25.What is the hiring plan for the next 12 to 18 months?What good looks like: Roles tied to the roadmap and the budget, with a realistic view of how long each hire takes.

Does the company actually own what it is selling?

1. 26.Are code repositories, cloud accounts, domains and app-store accounts owned by the company?What good looks like: All in company-controlled accounts with at least two admins; none in a founder's, freelancer's or agency's personal name.
2. 27.Has everyone who wrote code or designs assigned their IP to the company?What good looks like: Signed IP-assignment and confidentiality terms for employees and contractors, including early freelancers.
3. 28.Which open-source licences does the product use?What good looks like: A licence scan of your dependencies, with any copyleft licences (such as GPL or AGPL) reviewed against how you ship or host the product.
4. 29.Do you rely on code, data or models you may not have the rights to use?What good looks like: Third-party code, datasets and model terms reviewed, with commercial use permitted.
5. 30.Could you move to another hosting provider or key vendor if you had to?What good looks like: You know your lock-in points and the rough effort to move off each one.

Do you know how the product is used, and is the data fit for the next stage?

1. 31.What do you measure about how customers use the product?What good looks like: Analytics on the key actions, and a handful of metrics the team actually reviews.
2. 32.Will the data model support the next stage of the roadmap?What good looks like: The core entities and relationships can carry the planned features without a rewrite.
3. 33.How good is your data, and who owns its quality?What good looks like: Validation where data comes in, a named owner, and known gaps written down.
4. 34.Can customers export or delete their data?What good looks like: A working, tested way to handle export and deletion requests.
5. 35.How does the roadmap connect to revenue and customer feedback?What good looks like: Each major roadmap item traces back to customer evidence or a business goal.

If AI is in the product or the pitch, investors will ask how it is controlled.

1. 36.Which AI models and vendors does the product depend on, and what happens if one changes?What good looks like: Models and vendors listed, with a tested fallback or a clear plan to switch.
2. 37.How do you know the AI output is good enough?What good looks like: An evaluation set of real examples, re-run whenever prompts or models change.
3. 38.How is the product protected against prompt injection and misuse?What good looks like: Untrusted input kept apart from instructions, tools given the least permissions they need, and checks before sensitive actions.
4. 39.What customer data is sent to AI providers, and can they train on it?What good looks like: You know exactly what is sent, it is kept to the minimum, and the providers' retention and training terms have been reviewed.
5. 40.What does AI cost per customer, and is it capped?What good looks like: Cost per request tracked, with rate limits and budget alerts in place.