For investors & acquirers
Technical Due Diligence
You're about to write a check based on a demo and a pitch deck. We read the code, meet the team, and tell you what you're actually buying — in one report with a clear risk score.
Why the demo isn't evidence
A working demo proves the happy path ran once, on the founder's laptop. It says nothing about what happens at 10x the users, whether the team can ship next quarter's roadmap, or whether the codebase is three departed contractors' worth of unowned code.
AI-assisted development has widened that gap: a vibe-coded prototype can look shippable and still be six months from production-ready. That's not a reason to walk away from the deal. It's a reason to price the risk correctly — and you can't price what you haven't measured.
What we assess — use this checklist yourself
These are the seven dimensions we score in every engagement. Even if you never hire us, these are the questions worth asking before the term sheet is signed.
-
Technical roadmap
Does the codebase support where the company says it is going? We compare what has been promised to customers and investors against what the architecture can actually deliver, and on what timeline.
Red flag: the roadmap quietly requires a rewrite nobody has budgeted for. -
Architecture & scalability
Can the system grow 10x without a rebuild? We map the bottlenecks, single points of failure, and the parts held together with duct tape and good intentions.
Red flag: the scaling plan is "we'll move to microservices later." -
Team & processes
Who actually understands the system? We look at code review habits, testing discipline, deployment process, and the bus factor — how many people can leave before shipping stops.
Red flag: one person holds production access, the architecture knowledge, and the only working mental model of the code. -
Infrastructure & observability
Environments, CI/CD, backups, monitoring, alerting. The question behind all of it: if production broke right now, would the team know before the customers do?
Red flag: incidents are routinely discovered by customers, not dashboards. -
Security & compliance
Access control, secrets handling, data protection, GDPR posture, and how the product would survive an enterprise customer's security questionnaire.
Red flag: credentials in the repo history and one shared admin login for everything. -
AI tooling & workflows
How the team uses AI coding assistants — and whether generated code is reviewed, tested, and owned, or merged on faith. AI-assisted velocity is an asset only when someone can still explain the code.
Red flag: nobody on the team can walk you through the code that handles money or authentication. -
Burn rate & FinOps
What the product costs to run, and whether unit economics survive growth. Cloud spend, AI and API costs per customer, and who — if anyone — is watching the meter.
Red flag: infrastructure cost grows faster than revenue and it is nobody's job to notice.
Extra scrutiny for vibe-coded products
Codebases built at AI speed fail differently. When a product was largely generated, we add checks that traditional due diligence skips:
- Tests that test something. AI assistants happily generate test files that assert nothing. Coverage numbers mean little until you read what's being asserted.
- Can the team change code they didn't write? We pick a real module and ask an engineer to walk through it. Hesitation here is the single best predictor of post-acquisition velocity.
- Dependency sprawl. Generated code pulls in packages nobody chose deliberately. We inventory what's actually load-bearing and what's abandoned upstream.
- License contamination. Generated code and copy-pasted snippets can carry licenses incompatible with a commercial product. This surfaces late in deals and kills them.
- Secrets hygiene. Fast prototyping and clean secrets management rarely travel together. We check the repo history, not just the current state.
How it works
-
Scoping call
30 minutes, free. Deal size, timeline, what access is realistic, what worries you.
-
Access
Read-only repo access, existing documentation, and two or three team interviews. NDA as standard.
-
Assessment
Days to two weeks, scoped to your closing timeline.
-
Delivery
Written report with a risk score, an investment recommendation, and a roadmap to production-ready — plus a walkthrough call and follow-up questions answered.
Frequently asked questions
How long does technical due diligence take?
From a few days to about two weeks, depending on codebase size and deal timeline. We scope it on the first call, and we respect closing deadlines — a late report is a useless report.
What access do you need?
Read-only access to the repositories, whatever architecture and process documentation exists, and interviews with two or three key people on the team. We work under NDA as standard, and no code leaves the target's environment.
How disruptive is it for the founding team?
A few hours of interviews, total. Most of the work happens in the code and the documentation. Founders regularly tell us they learned something about their own system from the report.
What happens if the code is bad?
Bad code is not a dealbreaker — unpriced risk is. Plenty of great companies run on messy codebases. The report tells you what it costs to fix and how long it takes, so you can negotiate terms instead of walking away or overpaying.
Do you assess AI-generated codebases?
Yes — increasingly they are the default. AI-assisted codebases fail in specific ways that traditional checklists miss, so we test whether the team owns the code or just prompted it into existence.