Strategy
Technical Due Diligence: Prep Your Codebase
The term sheet is agreed, and then the investor's technical adviser emails: could they have read access to the repository, an architecture overview, and a list of everyone who has ever contributed code? For many founders it is the first time anyone outside the team has looked under the bonnet. Here is what reviewers examine, what they forgive, and how to prepare.
What do investors check in technical due diligence?
Investors check that your company owns its code outright, that nothing in it creates legal or security liability, and that the product can be run and scaled by people other than the ones who built it.
There is no fixed standard: a seed investor might send an adviser for an hour's call, while an acquirer might commission a specialist review lasting weeks. Nobody is grading code style. Reviewers look for anything that makes the company worth less than it appears, and for evidence that you know your weaknesses and have a credible plan for them.
The commercial side — traction, retention, unit economics — is covered in whether your SaaS is ready to raise.
The technical due diligence checklist
What reviewers commonly probe, and the first fix we'd make:
| Area | What reviewers look for | Red flag | Quick fix |
|---|---|---|---|
| IP ownership | All code assigned to the company in writing | Agency or freelancer code with no assignment | Confirmatory assignments from every contributor |
| Repositories | A company-owned organisation, current team only | Repos on a personal or agency account | Transfer repos, prune access, enforce MFA |
| Open-source licences | A dependency and licence inventory | Unreviewed copyleft (GPL, AGPL) code | Licence scan; replace or isolate problem packages |
| Security | Secrets out of the code, dependencies patched, MFA everywhere | Keys in git history, known critical vulnerabilities, shared admin logins | Rotate keys, switch on scanning, enforce MFA |
| Architecture | A clear view of what breaks first at 10x | No diagram, or "we'll rewrite it after the round" | A one-page overview with known limits |
| Tests and CI | Critical paths tested on every change | No tests; deploys from someone's laptop | CI plus tests on auth, payments and the core flow |
| Documentation | New engineers productive within days | Setup knowledge in one person's head | A README from clone to running app |
| Infrastructure and cost | Company-owned accounts, spend in line with usage | Production in the agency's cloud account | Transfer accounts; know the bill without credits |
| Data protection | What personal data you hold, where and why | No DPAs; production data on laptops | Data map, processor DPAs, an accurate privacy policy |
| Key-person risk (bus factor) | Knowledge spread beyond one person | Only one developer can deploy | A company password manager and a second deployer |
On licences, permissive ones such as MIT and Apache 2.0 rarely worry anyone. Copyleft can: the GPL may require you to publish source code when you distribute software built on it (a mobile app counts), and the AGPL can extend that to software used over a network, which covers every SaaS product. Whether either applies depends on how the code is combined with yours, so reviewers want proof someone has checked.
Who owns your code?
Your company owns its code only if everyone who wrote it was an employee at the time or has signed a written assignment — and gaps here are the most common deal-blocker in technical diligence.
In the UK, copyright belongs to whoever wrote the code unless they wrote it as an employee in the course of their employment. That default catches:
- Agencies and freelancers. Paying the invoice does not transfer ownership; without a signed assignment, they may still own your product.
- Founders. Code written before incorporation belongs to the founder personally, and without an employment contract, later code may too.
- Early helpers. The friend who built the backend one weekend is an author too.
Run git shortlog -sne --all on every repository. Each name — plus anyone
whose work arrived as a zip file — should map to an employment contract or a
signed assignment. Where one is missing, get a confirmatory assignment signed
now, while relationships are friendly. Discovering an unreachable contractor
during exclusivity is far worse.
For new work, fix it in the contract; our software development contract checklist covers the clauses.
General guidance, not legal advice. Have a solicitor draft anything material.
What counts as a red flag versus normal technical debt?
Normal technical debt is a cost a reviewer can see and size; a red flag is a risk they can't bound — usually legal, security, or a dependency on one person.
Every startup codebase carries debt, and experienced reviewers expect it. Messy modules, thin tests outside the critical paths, manual operational steps: none is a red flag on its own. A tidy monolith reads as sound judgement, not weakness — see monolith vs microservices for an MVP.
Red flags are different in kind:
- Anything legal. Unassigned IP, unreviewed copyleft, personal data with no lawful basis.
- Anything that exposes customers. Secrets in the repository, missing authorisation checks, no tenant isolation.
- Anything hidden. Undisclosed debt reads as concealment. The same debt in a one-page register, with a plan per item, reads as competence.
- Anything that blocks what the round funds. If the money is for enterprise sales and the product can't pass a security questionnaire, that isn't debt. It's the roadmap.
Tempted to start again? Weigh up whether to rebuild or refactor your MVP first. A rewrite announced mid-raise tells a reviewer their asset is about to be thrown away.
What does good enough look like at seed versus Series A?
There is no official bar, but as a rule of thumb it rises with the cheque:
| Area | Good enough at seed | Reasonable by Series A |
|---|---|---|
| Security | No secrets in code, MFA on, criticals patched | Scanning in CI, access reviews, a pen test if selling to enterprises |
| Tests and CI | Critical paths tested, automated deploys | Tests enforced in CI, a staging environment |
| Documentation | A README that gets an engineer running | Architecture notes and incident runbooks |
| Key-person risk | Company-owned credentials, two people who can deploy | No system that only one engineer understands |
Ownership is the exception: it must be clean at every stage.
How far ahead should you prepare?
Start two to three months before you plan to raise, and start on IP ownership immediately, because it depends on people you don't control.
Diligence usually happens after a term sheet, against a deadline — the worst time to find a missing assignment or a leaked key. Most technical fixes fit into a few sprints alongside feature work, but tracking down a freelancer from three years ago can take weeks.
Build a technical data room as you go — architecture overview, licence inventory, contributor contracts, debt register — so a reviewer gets an organised folder on day one.
Then stay clean: security scanning, uptime monitoring and backups are what our fixed-price maintenance plans cover. If you're earlier than all this — still working out how to fund your MVP — just set things up properly from the first commit.
Your pre-due-diligence checklist
Copy this and work through it before you raise:
- Every name in
git shortlog -sne --all, founders included, has a contract or IP assignment - Repositories and cloud accounts owned by the company, former contributors removed
- MFA on code hosting, cloud, email, payments and the domain registrar
- No secrets in the code or its history; anything ever committed rotated
- Dependency and secret scanning on, criticals patched, GPL and AGPL usage reviewed
- One-page architecture overview, including what breaks first at 10x
- CI running tests on auth, payments and the core flow
- A README that takes a new engineer from clone to running app
- Data map, processor DPAs, and a backup you have actually restored
- Two people can deploy; a one-page debt register with a plan per item
Frequently asked questions
Can technical debt kill a funding round?
Ordinary debt rarely does — hidden debt, security holes and ownership gaps are what stop deals. Reviewers expect rough edges in a young codebase. Debt turns dangerous when it is undisclosed, when it blocks the roadmap the money is for, or when fixing it means an unbudgeted rewrite.
Should I get an independent code audit before raising?
Yes — an audit before the round finds the problems while you still control the timeline. Better to hear about a leaked key from someone you hired than from someone deciding whether to invest. A short paid audit is how we'd start: a few days of senior engineering time, ending in a written, prioritised fix list that our software development team can work through, or hand to yours.
What if an agency or freelancer built our product?
Get a signed IP assignment from them first — without one, they may still own your code. Most reputable agencies sign a confirmatory assignment without fuss once invoices are settled. Ask at the same time for repository and cloud account transfers, credentials and documentation, and involve a solicitor early if they won't cooperate.
The bottom line
Technical due diligence is not an exam you pass with perfect code. Own your code outright, keep secrets out of the repository, know your licences, write down your architecture and your debt, and make sure more than one person can run the product.
Raising in the next six months? Book a free scoping call and we'll scope a pre-due-diligence code audit: a written verdict on what a reviewer will find, while there's still time to fix it.
Keep reading
Leave a comment