By the time a software company raises a Series B, investors are usually paying for more than product-market fit. The money may be earmarked for more customers, bigger contracts, faster product development, more hiring or a move into new markets.
Technical due diligence has to answer a plain question: can the technology, and the engineering organization behind it, carry that growth?
Elegance is beside the point. A Series B company can carry technical debt and still be a sound investment. What the investor needs to know is which weaknesses are manageable, which will eat capital or time, and which knock out an assumption the investment depends on.
Fundz has looked at the other side of this in When Growth Becomes Execution Risk: What Investors Should Watch After Expansion: once growth arrives, investors need evidence that the operating model is absorbing it. Technical diligence comes earlier and asks what has to be true, technically, for the planned growth to work.
Key Points: What Series B Technical Diligence Should Establish
- Start from what the round is meant to fund, and test the technology against those growth assumptions.
- Five areas cover most of the ground: architecture, release reliability, security, concentration of engineering knowledge and the cost of remediation.
- Records beat reassurance. Delivery metrics, incident history, security findings and ownership maps say more than a polished presentation.
- Each material finding falls into one of four categories (thesis challenge, underwritable remediation, post-investment milestone or ordinary technical debt), largely depending on what fixing it would do to the use of proceeds, the roadmap and the revenue plan.
- A finding can be fixed before closing, written into the investment documents as an obligation, reflected in the terms or end the deal. Questions that could change the price belong before the term sheet.
Start With What the Round Is Meant to Fund
A technical review works best when it starts from the assumptions the investment rests on. If the plan calls for doubling customer volume, moving upmarket, launching new products or improving gross margin, those requirements should shape the diligence.
Materiality follows from the plan. An architecture limit matters if it makes the growth forecast harder or costlier to hit. A slow, fragile release process matters if the roadmap depends on shipping faster. Security gaps weigh more heavily when the company is chasing enterprise accounts with strict requirements, and a key-person dependency becomes serious when the team is expected to grow fast without losing its grip on the product.
KPMG's guidance on technology due diligence for software investments makes a similar point, framing tech diligence as a way to understand whether a platform's architecture can scale to support the investment thesis. KPMG is writing about transactions such as acquisitions. In a Series B, the same finding is more likely to move the use of proceeds, the roadmap or the terms of the round.
Five Questions That Turn Technical Findings Into Investor Evidence
1. Can the Architecture Carry the Growth Being Funded?
Microservices, containers and a well-known cloud provider say little about scalability on their own. What an investor needs to know is where the current system hits its practical limits, and what happens as it gets close.
Google Cloud's Well-Architected reliability guidance starts with understanding how a system's components interact, how data and actions flow through it, and where failures, bottlenecks and risks can occur. From there it stresses redundancy, horizontal scalability, monitoring and tested recovery. That shifts the conversation from architecture labels to how the system behaves.
Ask for a credible account of what will fail first, how much headroom is left and what work has to happen before the next growth step. A monolith can be a sound design at this stage, and a distributed architecture can still buckle under load.
Where infrastructure operations are outsourced, the provider's scope becomes part of the evidence. The page linked as tech deployment by C-Cured lists remote monitoring, patch management, backup and recovery, and cloud and Azure support. The diligence question is which of these the startup actually relies on, and whether recovery has been tested.
2. Can the Team Ship Faster Without Making the Product Less Reliable?
A Series B often raises the pressure on the roadmap. More engineers, more customers and more promises to keep all push toward shipping faster, which makes delivery performance part of the growth case.
DORA currently uses five software-delivery measures: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, grouped into throughput and instability. They measure software delivery performance, and they also tell an investor what to look for: how fast changes reach production, how often releases cause trouble and how much unplanned work follows.
Read them alongside the incident log. A team that ships slowly may have a good reason, and one that ships quickly may be generating instability.
3. Does the Security Evidence Support the Customers in the Plan?
A startup selling primarily to small businesses may face a different evidence burden from one moving into regulated enterprises, handling more sensitive data or signing contracts with detailed security schedules.
NIST's Secure Software Development Framework gives software producers and the organizations that buy from them a common vocabulary for secure development. An investor cares less about whether a company can name the framework than about whether the practices behind it are running: who owns secure development, how vulnerabilities are tracked, and whether serious findings get closed or keep sliding.
Many startups buy part of this from outside providers. Awecomm in the industry is one provider example: its cybersecurity page lists assessments, penetration testing, threat monitoring and vulnerability scanning, alongside alignment with frameworks such as NIST and CIS. If the company uses one, diligence should establish which services it actually buys, what the latest findings were and who owns remediation.
4. How Concentrated Is Engineering Knowledge?
A product can be technically sound and still carry execution risk if too much knowledge or authority sits with one founder, architect or senior engineer. Departure is only part of the risk. Concentration slows hiring, releases, incident response and technical decisions even when nobody goes anywhere.
Look at who owns each service, who reviews code, who can deploy and who is on call. Then ask: if one or two people were unavailable during the next stage of growth, which commitments would get harder to keep?
5. What Will Remediation Consume?
Here technical diligence turns into capital allocation. How much a finding matters depends largely on what it will take to fix.
A good report turns each material finding into an owner, a remediation path, an estimate of time and cost, the effect on the roadmap and the risk that remains. For a Series B investor, the deciding issue is whether that work is already in the use of proceeds. If the plan assumes nearly all new engineering capacity will go into customer-facing features, and diligence shows much of it must first go into stabilizing the platform, the technical finding has become a problem for the investment model.
What Evidence Can Test Those Assumptions?
A founder's explanation is a starting point. Diligence gets stronger when that explanation can be checked against records. Every data room is different, but useful material includes:
- A current architecture diagram showing critical services, data flows and external dependencies.
- Capacity, performance and reliability data relevant to the growth forecast.
- Deployment and change data, recent incident history, rollback procedures and post-incident actions.
- Security assessments, penetration-test findings, vulnerability-management records and remediation owners.
- A software and third-party dependency inventory, including material licensing or end-of-life exposure.
- An engineering responsibility map showing who owns critical systems, repositories, deployments and production access.
- Cloud and infrastructure cost trends, where the thesis depends on margin improvement or scale economics.
- A technical-debt and remediation backlog with priorities, dependencies and realistic estimates.
A bigger data room is no virtue in itself. The point is whether management's claims hold up against the records.
How the Review Fits Into the Round
Timing shapes what a technical review can change. Gunderson Dettmer's primer on venture financing due diligence explains that while an investor may start business diligence earlier, full legal due diligence usually waits until a term sheet is signed, because it involves requesting large amounts of confidential information.
A technical review run in that phase reports back while the documents are being drafted and the headline terms are already agreed in principle.
The time available is limited. In a survey of 885 venture capitalists conducted in 2015 and 2016 by Paul Gompers, Will Gornall, Steven Kaplan and Ilya Strebulaev, the average deal took 83 days to close, and the average firm spent 118 hours on due diligence over that period, a total that covers every area of review, technical or otherwise.
Competition can push the work later still: Nicolas Sauvage, president of TDK Ventures, writes that when time is of the essence, investors may shift more of their diligence to after the term sheet.
In Fundz's view, that sequence has a practical consequence. When technology is central to the investment thesis, the technical questions that could change the price or structure of the round should be asked before the term sheet is signed, while there is still room to act on the answers. Confirmatory work, such as a code audit, can follow.
Depth varies widely. Kyle Wild, founder of Root System, told TechCrunch in 2023 that "it's remarkably uncommon for there to be a code review, even for Series A and Series B investment," while the financials get "a full-on clinical inspection of the books." Where an investor does want to see code, access has to be negotiated.
What a code audit turns up can matter. Black Duck's 2026 analysis covered 947 audited codebases representing 197 M&A transactions, with the codebases submitted between November 2024 and October 2025. It found license conflicts in 68% of codebases and at least one high-risk vulnerability in 78%. The evidence comes from acquisitions rather than venture rounds, but it makes a good case for putting a dependency inventory in a Series B data room.
When an investor brings in an outside reviewer, the brief matters more than the reviewer's reputation. Scope the work to the one or two questions where the plan is most exposed, ask for findings in the form the investment committee will use (an owner, a cost, a timescale and a category for each), and agree in advance what access the reviewer will have.
It is also worth asking whether the reviewer hopes to win the remediation work afterwards, since that can color how findings are framed.
When something does turn up, the options are limited. Gunderson's primer notes that an issue can be dealt with before closing or after it, for example through a provision in the investment documents requiring a fix within a set period.
A bigger finding can reopen the deal. Cooley GO's definition of due diligence notes that when diligence shows a company's representations to be inaccurate, the parties must consider "whether a change in the deal terms or termination of the deal is triggered." The four categories below line up with those responses.
Turn the Findings Into an Investment Decision
A list of red, amber and green observations is only a start. Each material finding should either change an investment assumption or be judged, deliberately, to leave it alone. One way to sort them is into four categories:
- Thesis challenge: the technology cannot support a central growth assumption without a redesign, delay or cost that the plan does not reflect.
- Underwritable remediation: the issue is real, but management understands it, the fix is credible and its cost and timing can be built into the investment case.
- Post-investment milestone: the risk need not block the round, but it needs a named owner, a timetable and proof of closure after funding.
- Ordinary technical debt: the issue is known, contained and unlikely to affect the growth thesis, customer commitments or material use of capital.
Features ship before every internal process is mature, and architecture that suited the first thousand customers may need to change for the next ten thousand. That kind of debt comes with growth. The warning signs are debt nobody owns, incidents that keep recurring, bottlenecks nobody can explain and repeated promises that a future rewrite will fix everything.
An Illustrative Example
Consider a hypothetical business-software company raising a Series B to move from mid-market customers into enterprise accounts and triple its customer base within two years. Its technical review produces four findings:
| Finding | Assumption affected | Category | What it changes |
|---|---|---|---|
| Load tests show the main database can handle about twice today's peak volume; the plan needs three times | Customer growth | Underwritable remediation | Two quarters of database work are funded from the proceeds, and the feature roadmap moves back accordingly |
| The first enterprise prospects require a SOC 2 Type II report, and the company's planned observation period means the report would not be issued until after those deals were forecast to close | Enterprise revenue timing | Thesis challenge | The revenue plan is re-forecast, and the investor revisits valuation or other terms |
| Only the CTO and one senior engineer can deploy to production or diagnose the billing service | The team can grow without losing control | Post-investment milestone | A named owner has 90 days to document the service, widen access and add on-call coverage, with progress reported to the board |
| The internal admin tool runs on an outdated front-end framework but is rarely changed and never seen by customers | None central to the plan | Ordinary technical debt | Stays on the backlog |
Only one of these findings challenges the thesis, and it concerns timing more than technology. The database work is real, but it can be priced into the use of proceeds. The key-person risk can be handled after closing, as long as someone owns it. The admin tool can simply wait. An investment committee can act on that.
The four categories are Fundz editorial analysis rather than an industry scoring standard. The same discipline applies after a deal closes. In After the Acquisition: What Should Be Integrated First to Protect Deal Value?, Fundz argued that integration work should follow the value case. Before a Series B, the equivalent is asking whether a technical issue changes the case for putting new capital in.
The Technical Question Behind the Series B
In the end, technical due diligence answers one business question: can this company's technology and engineering organization carry the Series B plan it is presenting?
Answering it takes enough evidence to show what can scale, what must be fixed, what the fixes will cost and which risks remain after funding. If those answers change the growth plan or the use of proceeds, the findings belong in the investment decision, not in an appendix.
Questions Investors Ask About Series B Technical Due Diligence
Does every Series B investor run a formal technical due-diligence review?
No. Depth and format vary with the investor, the sector, the product's complexity and how central technology is to the investment case. What matters is whether the investor has enough technical evidence for the decision in front of it.
Does technical debt automatically make a startup less investable?
No. Technical debt comes with growth. The better questions are whether management knows where it sits, whether it is causing measurable problems, what fixing it will take and whether it conflicts with the growth plan.
What evidence best shows that a software platform can scale?
Capacity tests, production performance data and reliability history, plus a credible explanation of what has to change before the next step-up in demand. Architecture diagrams help, but they show intent more than behavior.
Are SOC 2 or ISO 27001 enough to settle the security question?
Not on their own. Assurance reports and certifications are useful evidence about defined controls and scope. Investors still need to know which systems they cover, what the recent findings and open vulnerabilities look like, and who owns remediation for the products and customers in the plan.
How should investors treat outsourced IT or engineering support?
As part of the operating model. Establish what the provider owns and what stays in-house. An outside provider can run the infrastructure while critical product knowledge still sits with a few people inside the company.