Your Series B term sheet is conditional on technical diligence. You have three weeks. Here's what's actually on the checklist — and what they find in the first hour.
Most founders assume technical due diligence is a formality. It's not. Failed diligence kills rounds. Not often — but it happens, and when it does, it usually surfaces one of four things: no test coverage on critical paths, credentials committed to git history, a schema that can't handle 10x the current load, or architecture that requires a rebuild to support the product roadmap in the term sheet.
These aren't obscure edge cases. They're the first things a diligence engineer looks for, and they find them fast.
What technical due diligence actually covers
Technical due diligence at Series B typically takes 2–4 weeks with a team of 2–3 engineers. They're looking at six domains, and they have a framework for each.
Architecture and scalability. What does the system look like at 10x users? At 50x? Where are the bottlenecks? Is the data model capable of evolving? Are there single points of failure? Is there a clear separation of concerns — can individual components be scaled independently?
They're not looking for microservices. They're looking for decisions that reflect an understanding of the load the system will eventually carry. A monolith is fine. A monolith with a schema that can't be sharded or migrated without downtime is a risk.
Security posture. Auth implementation, secrets management, data encryption, dependency vulnerabilities, access controls. Specifically: are there credentials in the git history? Is there a policy for secret rotation? Are dependencies audited for known vulnerabilities?
The git history check takes about 30 seconds with the right tooling. It's one of the first things they run.
Code quality. Test coverage, error handling, code organization, documentation. Not whether the code is beautiful — whether it's maintainable. Can a new engineer join the team and contribute safely in their first two weeks? Are there tests that would catch a regression on a critical path?
Infrastructure and reliability. Deployment pipeline, monitoring, alerting, incident history. Do you know when things break? How fast do you recover? Is there a runbook?
Team and process. How do decisions get made? Is there a technical lead with a clear vision? How are architectural decisions documented? Is there a meaningful code review process, or is it a formality?
Documentation and knowledge transfer. Is the system documented? Not exhaustively — but enough that a new CTO or a senior hire can onboard without the founding engineers in the room?
The specific red flags that kill deals
These are the things that turn a conditional term sheet into a renegotiation or a pass:
Credentials in git history. Database passwords, API keys, AWS credentials committed at any point in the history. They run git log --all -S "password" and variations. If they find it, the question becomes: what else don't you know about? The signal isn't the specific credential — it's the security posture it implies.
No test coverage on critical paths. Not 80% coverage everywhere. Specifically: no tests on the payment flow, the auth flow, the data pipeline if applicable, or whatever the core value-delivery mechanism of the product is. If the most important thing your product does has no automated verification, that's a reliability risk at scale.
Schema that can't handle growth. Tables with no foreign key constraints, joins that work at current load but become O(n²) at 10x, soft deletes implemented as a boolean column that's not indexed, multi-tenant data mixed without isolation. The schema tells the story of how the system was built. A schema that looks like it was designed sprint-by-sprint without a model shows.
No error handling. Catch blocks that swallow exceptions. No retry logic on external dependencies. No dead-letter queue for async operations. No meaningful alerting. The system works when everything works — and the team finds out about failures when users report them.
Architecture that contradicts the roadmap. The investor's term sheet describes a product direction. If the current architecture can't support that direction without a rebuild, that's a risk they're pricing into the deal. They'll ask specifically: "how does the current system support [feature in the roadmap]?" If the answer is "we'd need to redesign that part," that's a finding.
Key-person dependency with no documentation. One engineer who understands the system, no documentation, and no evidence of knowledge transfer. This is a retention risk and a scalability risk. Investors are pricing in the cost of growing the team; if the system requires the founding engineer to explain everything to every new hire, that's expensive.
What "passing" diligence looks like
Passing diligence doesn't mean a perfect codebase. It means a codebase that reflects good judgment and managed tradeoffs.
Specifically, passing diligence looks like: a clear architecture diagram that matches reality. A test suite that covers critical paths. A migration history that tells a coherent story about how the product evolved. No credentials in git. Structured logging and at least basic alerting. A README that tells you how to run the system and how it's organized.
The diligence engineer doesn't need to be impressed. They need to leave with confidence that the system can support the product roadmap, that the team has made intentional decisions, and that the risk is manageable.
The questions they ask at the end of diligence tell you how it went. Questions about specific technical choices ("why did you go with this approach for X?") mean they're curious and engaged — that's fine. Questions that are really risk items in disguise ("have you considered how you'd handle X?") mean they found something. You want all the questions to be the first kind.
How to prepare if you have 30 days
Thirty days is enough time to address the most common diligence findings. Not to rebuild the system — to surface the things that are findable and fix them before someone else finds them.
Week one: the security audit. Run git log --all and look for credentials. Rotate any that appear. Move secrets to a secrets manager if they're not already there. Run a dependency vulnerability scan (npm audit, pip audit, or equivalent) and address critical findings. Review your auth implementation: sessions, token expiry, privilege escalation surface.
Week two: the test coverage audit. Map your critical paths — payment, auth, core value delivery — and look at test coverage for each. Fill the gaps on the paths that matter. You don't need to achieve 80% overall; you need to cover the things that can't fail.
Week three: the documentation sprint. Write or update the architecture README. Diagram the system as it actually is. Document the decisions that a diligence engineer will ask about. Write a runbook for common operational events.
Week four: the readiness review. Have an external engineer — not someone on the team — do a structured walkthrough. Brief them on the product, give them access to the codebase, and ask them to come back with findings in two days. Fix everything they find that you can fix in a week.
This preparation isn't about hiding problems. It's about ensuring the problems that exist are the ones you've consciously chosen to accept, rather than the ones that slipped in without a decision.
Ideally this work is done long before the term sheet. The companies that pass diligence easily are the ones where an architect has been asking "would this survive diligence?" for the past 18 months, not the ones who started preparing three weeks before the call.
The questions the diligence engineer will ask
Some version of these, every time:
"Walk me through the data model." They want to see if you understand it or if you're describing it from memory without being able to explain the decisions.
"How does the system behave when [external dependency] is unavailable?" They're probing for error handling and resilience thinking.
"What's your deployment process?" They want to know if it's automated, if there's a rollback plan, and how long deployments take.
"How do you know when something breaks in production?" This is the observability question. "We check the logs" is not the answer they're hoping for.
"What would you build differently if you were starting today?" This question isn't a trap — it's an invitation. A technical team that has clear answers here is a team that's learned from the system and can build the next thing better. The wrong answer is "nothing, it's great."
"What technical debt are you carrying and what's the plan?" Same dynamic. They know debt exists. They want to know you know it too.
What this looks like when it's resolved
A company that passes diligence without anxiety has been building to this standard all along. The preparation isn't frantic because there's nothing to hide.
The architecture is documented because it was documented when it was built. The tests exist because tests were written when features were written. The credentials aren't in git because they were never in git. The schema tells a coherent story because the data model was designed before the first migration.
This is the specific advantage of working with an architecture partner rather than a dev shop from the start: the things that pass diligence are the same things that make the system maintainable, extensible, and operable. You don't build them for diligence. You build them because they're correct. Diligence just confirms it.
This is for you if
You're a Series A or early Series B founder, or the CTO of a company approaching a raise, and you have a system built fast that you haven't looked at critically in 12–18 months. You want to know what the diligence engineer is going to find before they find it.
The preparation engagement starts with a structured audit against the actual diligence framework — not a general "code review" but a specific pass against the things that kill rounds. Typical engagement at this stage runs $100k+.
This is not for teams with 90 days before a close who want surface-level cleanup. It's for teams who are 6–12 months out and want to get ahead of the findings. If you're inside 30 days, the preparation is still worth doing — but set expectations appropriately about what's fixable in that window.