Technical due diligence: what investors check in your codebase before a Series A

Technical due diligence looks beyond whether the product works. Investors want to know whether you own the code, whether your team can maintain and operate it, whether your open-source dependencies create legal obligations, whether the system has serious security weaknesses, and whether the architecture can support the company's growth plans.

Before a Series A investor puts money into your company, they need to know what they are actually buying into. That includes your codebase. These problems can become expensive during a funding round. A contractor may own rights you assumed belonged to the company. An open-source dependency may impose licence obligations you did not know about. A critical vulnerability may expose the product to attack. An architecture built for a small team may become a constraint as the company scales. Finding these issues during due diligence can slow a deal or create additional work when you are already under pressure to close the round.

The good news is that most of these risks can be identified before an investor asks about them. Preparing your codebase for technical due diligence gives you time to fix problems, document what you own, and explain the decisions behind your architecture. Black Duck found licence conflicts in 68% of the 947 commercial codebases in its 2026 audit report. For a founder preparing for a Series A, that is a reason to check your dependencies before they become an investor's question.

Key takeaways

• Under US law, code written by a contractor is considered a work made for hire only when it falls within one of nine specified categories and both parties have signed a written agreement stating that it is a work made for hire. Software is not one of those nine categories. A copyright transfer also needs to be in writing and signed by the copyright owner.
• Black Duck's 2026 audit data covered 947 commercial codebases, including 197 involved in M&A transactions. Open-source software appeared in 98% of the codebases, while 68% had licence conflicts. That was an increase from 56% the previous year.
• Section 13 of the GNU Affero General Public License v3 requires a modified version of AGPL-licensed software to offer its corresponding source code to all users who interact with it remotely over a network. This is why investors may pay particular attention to AGPL code used in a hosted product.
• The EU Cyber Resilience Act requires manufacturers to draw up a machine-readable software bill of materials covering at least top-level dependencies. Its reporting obligations applied from 11 September 2026, while its main obligations apply from 11 December 2027.
• Exploited software vulnerabilities are a major route into breaches. Verizon's 2026 report found that 31% of breaches began through exploitation of vulnerabilities. Mandiant's analysis found that exploits accounted for 33% of the intrusions it investigated in 2024.

In this article

• What is technical due diligence, and when does it happen?
• What do investors actually check?
• How does an open-source licence scan work, and what does it flag?
• Which findings change the terms, and which are noise?
• How do you prepare in 90 days?
• How does diligence differ at seed, Series A and acquisition?
• Where RocketDevs fits
• Conclusion
• Frequently asked questions

What is technical due diligence, and when does it happen?

Technical due diligence is an investor's way of checking whether the claims you are making about your technology, intellectual property and development practices are accurate. It is not simply a test of whether your code is clean or well written. Investors also want to know whether your company actually owns the code, whether your developers have signed the right agreements, and whether your use of open-source software creates obligations that could affect the product.

The National Venture Capital Association's model Series A stock purchase agreement provides a useful example. It includes representations that employees and consultants have assigned their intellectual property rights to the company. It also addresses confidentiality agreements and the use of open-source and copyleft software. The purpose of technical due diligence is to establish whether those representations are accurate before the investment closes.

That makes technical due diligence closer to a title search than a code-quality exam. An investor is checking whether the technology they are investing in is actually owned by the company and whether there are legal or technical issues attached to it. The NVCA model stock purchase agreement asks the company to confirm that employees and consultants have assigned relevant intellectual property rights to it. It also requires the company to confirm that current and former employees, consultants and officers have signed confidentiality and proprietary information agreements. The agreement addresses the use of open-source and copyleft code, including software covered by the General Public License and Lesser General Public License. The version available from the NVCA was last modified in 2018, so investors and their lawyers may use different and more current documents for an actual transaction.

When does technical due diligence happen?

Technical due diligence usually becomes more formal after a term sheet has been signed. CRV states that formal due diligence after a signed term sheet often takes about six weeks. Its Series A data-room guidance also says investor counsel typically begins by reviewing documents such as the cap table, Certificate of Incorporation and intellectual property assignment agreements.

For a founder, that six-week period is not a comfortable window in which to start looking for problems. It is the period when gaps you have not already fixed can become questions in the investment process. If an agreement is missing or ownership of part of the code is unclear, you may have to resolve it while the investor is already reviewing the company.

The good news is that you usually have much more time to prepare than those six weeks suggest. Carta's data from 9,843 funding rounds shows that the median time between a seed round and a Series A was 1.9 years in Q4 2025. That gives you a substantial window to clean up your intellectual property records, review your dependencies, document your architecture and address security issues before formal diligence begins.

Most of the preparation in this playbook can be done during the final quarter before a Series A. If you are still working out how many engineers you need to reach the point where you can raise a seed round, that is an earlier stage of the process. See RocketDevs' guide to how many engineers you need to raise a seed round.

What do investors actually check?

Investors are looking for risks that could affect the value of the company or the deal. In a technical due diligence review, five areas usually matter most: who owns the code, who can operate it, what your software licences require you to do, how exposed the product is to attack, and whether the architecture can support the growth described in your pitch deck.

The first and third risks connect directly to the intellectual property and open-source representations found in venture investment documents. Security matters because software vulnerabilities are a major route into breaches. Architecture matters because investors need to understand whether the technology can support the business they are being asked to fund.

1. Who owns the code?

Ownership comes first because it is both a legal issue and a basic question about what the investor is actually buying. If an employee writes code within the scope of their employment, the company may own the resulting copyright under applicable law and agreements. Code written by a contractor or another third party can be different. Ownership may remain with the person who created it until a valid written agreement transfers the relevant rights.

That is why investors want to see the chain of title. They may check whether founders, employees and contractors have signed appropriate intellectual property assignments and whether those agreements cover the code that is actually part of the product. If an important part of the codebase belongs to someone outside the company, that can become a problem during the investment process.

2. Who can run the system?

The second question is what happens if one of your key developers leaves tomorrow. Can someone else deploy the product, investigate a production problem and make a meaningful change without relying on that person?

This is often described as the truck factor: the number of developers who would have to leave before a project can no longer be effectively maintained. Researchers studying 133 popular GitHub projects found that 65% had a truck factor of two or less. These were open-source projects rather than startups, so the figure should not be treated as a startup benchmark. It does show that concentrated technical knowledge is common and can be measured.

A separate JetBrains study of 269 engineers found that the bus factor was perceived as an important problem in collaborative software development, per Bus Factor in Practice. An investor does not necessarily need a formal calculation to spot the problem. If one developer has written most of the code for your payments service and is the only person who knows how to deploy it, the concentration is already visible.

3. What do your open-source licences require?

Open-source software is almost certainly part of your product, even if your team did not deliberately choose every dependency. The issue for investors is not simply whether you use open source. They want to know whether the licences attached to that software create obligations for your company.

Black Duck's 2026 audit data found open source in 98% of the 947 commercial codebases it examined. It also found licence conflicts in 68% of those codebases. Black Duck sells software and services for identifying these risks, so its commercial interest should be taken into account when interpreting the figures.

Independent research also points to the prevalence of licence incompatibility. A peer-reviewed study that used its own detection method across 1,846 open-source projects found licence incompatibility in 72.91% of the projects it examined. The populations and methods differ, so these figures are not directly comparable. Together, they show why licence compliance can become a material diligence question.

4. How exposed is the product to attack?

Security is another risk investors can put a price on. A serious vulnerability can lead to a breach, operational disruption, remediation costs or damage to customer trust. Those consequences can affect the company's value as well as its ability to execute its growth plans.

Verizon's 2026 Data Breach Investigations Report found that 31% of breaches began with exploited software vulnerabilities. Mandiant's analysis of its own 2024 investigations found that exploits accounted for 33% of initial infection vectors, according to its M-Trends 2025 report on Google Cloud.

Smaller companies are not automatically outside the risk. Eurostat data show that 19.85% of EU enterprises with 10 to 49 employees reported an ICT security incident with real consequences in 2024. For a founder preparing for diligence, the practical question is whether you can demonstrate that security risks are identified, prioritised and being addressed.

5. Can the architecture support the plan?

Architecture is different from the other four risks because there is no single statute or dataset that can tell an investor whether your system is suitable for your business. Instead, the reviewer compares the technology with the company's plans.

If your pitch deck says the product will serve ten times as many customers, enter new markets or add major functionality, the investor may ask whether the current architecture can support that growth. They may also want to understand where the system will need to change and what those changes will cost.

You do not necessarily need a perfect architecture before a Series A. Early-stage companies often make technical trade-offs to get a product into the market. What matters during diligence is being able to explain those decisions and show how you plan to address known limitations.

If the honest answer is that part of the system will eventually need to be rebuilt, that does not automatically make the architecture unusable. The important part is having a documented plan, an estimated cost and a realistic timeline. Our guide on when to rewrite a product after traction explores that decision in more detail.

Technical due diligence is therefore not simply an investor asking whether your code is "good." It is an attempt to understand whether the technology is owned by the company, whether the team can operate it, whether its dependencies create obligations, whether its security risks are understood, and whether it can support the business you are asking investors to fund.

How does an open-source licence scan work, and what does it flag?

An open-source licence scan creates an inventory of the third-party software in your codebase. It identifies the licence attached to each component and checks whether the licence terms are compatible with the way you use and distribute that software.

The SPDX License List provides a shared vocabulary for this process. Version 3.29.0, released on 16 September 2026, contains 740 licence identifiers, including 154 identified as OSI-approved, per the SPDX license-list-data repository.

This is one part of technical due diligence that a technical founder can investigate before an investor asks about it. Understanding what the scanner is actually doing makes its report much more useful. A software composition analysis (SCA) scan generally works through four stages.

1. It builds a dependency graph

The scanner starts with the dependency information already maintained by your package managers. It can read files such as package.json and its lockfile, requirements.txt or poetry.lock, pom.xml, and go.mod.

This identifies the libraries your team deliberately added to the project. It also identifies their dependencies. These are known as transitive dependencies: software that your software depends on indirectly because one of your direct dependencies needs it.

That second layer can make the dependency list much larger than founders expect. Sonatype reported that the average Java application had about 150 open-source components when both direct and transitive dependencies were counted in its 2024 analysis.

A five-person engineering team is unlikely to have manually reviewed the licence terms for 150 separate components. The scanner is designed to make that inventory visible.

2. It looks for code that does not appear in a manifest

Dependency manifests only tell the scanner about software installed through the package manager. They cannot identify code that a developer copied directly into the repository.

That could include a library pasted into a /lib directory, a code snippet copied from a website, or code introduced through another source without being recorded as a package dependency. AI-assisted development can create the same problem if generated code contains material from an external project but no dependency is declared.

For this reason, some SCA tools also use techniques such as snippet analysis, binary analysis and file fingerprinting. Black Duck's 2026 OSSRA report says organisations that rely only on dependency-manifest scanning can miss nearly one in six open-source components in their codebases.

That figure comes from a vendor describing the advantage of its own scanning approach, so it should be interpreted in that context. The underlying limitation is straightforward: a manifest cannot report code that was never installed or recorded through the package manager.

3. It identifies the licence and maps it to an SPDX identifier

Once the scanner finds a component or piece of code, it determines which licence applies to it. This can involve comparing licence text against a database of known licences.

The open-source ScanCode Toolkit, for example, detects licences, copyrights, package manifests and dependencies in source code and binary files. It can also produce results in formats such as SPDX and CycloneDX.

The SPDX project provides standard identifiers such as MIT, Apache-2.0, GPL-3.0-only and AGPL-3.0-only. Its licence list includes a standardised short identifier, the full licence name, the licence text and a permanent URL for each licence and exception.

That standardisation matters during due diligence. A scanner can identify a licence using the same identifier that your lawyers or investors recognise, making the results easier to compare across different tools.

However, an SPDX identifier does not automatically mean that a licence is open source. Licences such as SSPL-1.0 and BUSL-1.1 have SPDX identifiers but are not OSI-approved. "It has an SPDX identifier" and "it is open source" are therefore two different statements.

4. It applies a policy and raises findings

The scanner then evaluates the licences against a set of rules. Different tools organise licences differently, but a typical approach separates permissive licences from different forms of copyleft.

Permissive licences such as MIT, Apache 2.0 and BSD generally impose requirements such as preserving attribution. Weak copyleft licences such as LGPL and MPL can require modifications to the licensed component to be shared under specified conditions. Strong copyleft licences such as GPL v2, GPL v3 and AGPL can create broader obligations, depending on how the software is used and distributed.

The scanner can then flag several types of problem.

• Licence conflicts. Two licences may impose requirements that cannot both be satisfied. A copyleft licence may also create obligations that conflict with the way a company distributes a proprietary product. Black Duck reported licence conflicts in 68% of the 947 commercial codebases in its 2026 audit data.
• Missing licences. Some components may have no detected licence at all. Black Duck's 2026 data found that 8% of components had no detected licence, while another 11% carried custom or modified licences. A missing licence does not mean that the software is free to use. Copyright law generally gives the copyright owner exclusive rights over activities such as reproducing and distributing the work, as 17 U.S.C. 106 sets out.
• Known vulnerabilities. The scanner can match component versions against vulnerability databases and security advisories. In Black Duck's 2026 audit data, 78% of codebases contained at least one high-risk vulnerability and 44% contained at least one critical vulnerability.
• Abandoned components. The scan can also identify dependencies that have not been actively maintained. Black Duck found that 93% of the audited codebases contained components with no development activity for more than two years. An unmaintained dependency can become a problem if a vulnerability is discovered and there is no active upstream project to provide a fix.

What does this have to do with a software bill of materials?

The first stages of this process produce much of the information needed for a software bill of materials (SBOM). An SBOM is essentially an inventory of the components that make up your software, including information about dependencies and their versions.

That is why generating an SBOM and running a licence scan can often be part of the same preparation exercise. The tooling is already widely used. For example, the CycloneDX SBOM generator for npm recorded 1,859,261 downloads in the month leading up to 25 September 2026, per the npm registry.

For a founder, the practical takeaway is simple: do not wait for an investor to discover what is inside your dependency tree. Run the scan yourself, review the findings and understand which issues are genuine risks before technical due diligence begins.

Which findings change the terms, and which are noise?

Not every problem an investor finds in your codebase is going to affect the deal. The findings that matter most are the ones that create a legal obligation, raise a material security risk, or show that the company does not control an important part of its technology.

Ownership gaps are a good example. If a founder, employee or contractor contributed code without signing an appropriate assignment, the company may not have the rights it assumes it has. Strong copyleft can create another material issue when its obligations conflict with how you distribute or operate your product. Known exploitable vulnerabilities can also attract attention because they can create a direct security risk.

Other findings are usually less important on their own. An investor is unlikely to change the terms of a deal simply because they would have chosen a different framework or structured the application differently. Those technical preferences matter when they provide evidence of a larger problem with security, continuity or scalability.

Ownership gaps

An assignment gap can be both serious and relatively straightforward to fix. Under 17 U.S.C. 204(a), a copyright transfer is not valid unless the transfer is documented in writing and signed by the owner of the rights being transferred.

The practical point is that paying someone to write software does not necessarily mean the company owns the resulting intellectual property. Montague Law states that paying an invoice does not automatically transfer IP in its startup IP diligence guidance. KORE1, a technology staffing and consulting firm, similarly identifies contractor assignment documentation as something sellers frequently struggle to produce during technical due diligence and says missing paperwork can delay a transaction. These are advisers describing their own experience rather than independent measurements, so they should not be treated as statistics. They do, however, illustrate why this is worth checking early.

If early contributors worked as contractors, review the agreements covering their work and confirm that the relevant intellectual property rights were properly assigned. Contractor classification is a separate issue, but the documentation sits alongside the IP ownership question. See RocketDevs' guide to contractor classification for remote developers for more information.

Copyleft is a question, not a verdict

Finding GPL or AGPL code does not automatically tell an investor that there is a problem. The relevant question is whether the licence creates obligations that apply to the way your company uses and distributes the software.

Black Duck states that a GPL violation discovered during M&A due diligence can seriously affect a transaction. KORE1, meanwhile, notes that a GPL or AGPL component linked to a proprietary product is not automatically a disaster. These positions can coexist because the licence terms and the way the software is used determine whether particular obligations are triggered.

AGPL v3 Section 13 is especially relevant to hosted software. It addresses modified versions of the program that users interact with remotely through a computer network. That means the details of your implementation matter. An unmodified AGPL component used in one part of a system can raise a different question from an AGPL library that your team has modified and incorporated directly into a product.

The goal of a licence review is therefore not to eliminate open-source software. It is to make sure you know what you are using, understand the obligations attached to it and can explain why your use complies with those obligations.

Vulnerabilities are about your response, not perfection

No serious codebase is likely to have a completely empty vulnerability report forever. Investors and technical reviewers understand that vulnerabilities are discovered continuously. The more important question is whether your team knows about its vulnerabilities and has a process for dealing with them.

A known, critical and exploitable vulnerability that has been sitting in production without action tells a different story from a newly disclosed vulnerability that your team has already identified, assessed and patched.

Sonatype reported that 42 million vulnerable versions of Log4j were downloaded in 2025, representing 13% of Log4j downloads worldwide. It also found that a fix was available for about 95% of vulnerable component downloads.

For a founder, the lesson is practical: keep your dependency scans current, record what you have fixed and be prepared to explain anything that remains open. The existence of a vulnerability is not necessarily the diligence failure. Failing to know about it or failing to respond can be the bigger problem.

What is usually noise?

Framework choice, coding style and whether the reviewer personally prefers a monolith or a service-based architecture are unlikely to change investment terms on their own. Test coverage can also be a relatively minor issue if the parts of the system that matter most are well understood and properly maintained.

These issues become important when they provide evidence of one of the underlying risks. For example, poor test coverage on a billing system is not simply a style problem if it makes the system difficult to maintain or increases the chance of a serious production failure. That makes it a continuity or security concern.

The same principle applies to AI-generated code. The question is not simply whether an AI assistant was used. The diligence question is whether the resulting code is understood, maintainable, tested and properly incorporated into the company's development process. Our discussion of this issue is covered in the AI technical debt crisis.

The distinction is important because technical due diligence is not a competition to build the codebase an investor's engineer would have built. It is an assessment of whether the technology represents a manageable risk for the company they are considering funding.

A SAFE asks you to believe you own your code. A Series A purchase agreement asks you to sign that every employee and consultant assigned it to you.

How do you prepare in 90 days?

The best way to prepare for technical due diligence is to start with the work that takes the longest to complete. That usually means confirming who owns the code before moving on to software inventories, licence findings, security issues and operational continuity.

Within 90 days, you can build the core evidence an investor is likely to ask for. The plan below assumes one senior engineer and a founder who can spend several afternoons on the work.

1. Rebuild the chain of title: days 1 to 15

Start by establishing exactly who has contributed code to the company. Export the commit authors from your repositories and match each person to a signed agreement. If someone contributed without the right IP assignment, get a confirmatory assignment signed.

Former contractors can take the longest to track down, particularly if they are no longer working with the company. That is why this work starts first. You do not want to discover an ownership gap when an investor is already reviewing the company.

2. Scan the codebase and generate the SBOM: days 10 to 30

Run a licence and dependency scan across every repository. Use the results to generate a software bill of materials (SBOM) containing the information needed to identify the components in your software and their relationships.

The US Department of Commerce's minimum-elements guidance describes an SBOM as a formal record of the components used to build software. Its baseline includes seven elements: the supplier, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and a timestamp.

The guidance identifies SPDX, CycloneDX and SWID as SBOM formats. Pick one format and generate the SBOM directly from your scan rather than creating a separate inventory by hand.

3. Clear the licence findings: days 30 to 50

Next, work through the findings from the licence scan. Replace or isolate strong-copyleft components where their licence obligations do not fit how you use the software. Investigate components with missing or unclear licences.

For anything you decide to keep, document why. A short explanation of the component, its licence and how the company uses it can turn an unexplained finding into something the diligence team can understand and review.

The objective is not to remove every open-source dependency. It is to know what you use and be able to explain why your use is compatible with the relevant licence.

4. Patch and prove it: days 30 to 60

Address high and critical vulnerabilities and enable dependency alerts in your repository host. Keep the scan results from before and after the fixes.

That history matters because it shows how the team responds to security findings. A clean scan is useful evidence, but a record showing that the team identifies, prioritises and fixes vulnerabilities is more informative about the development process.

5. Lower the truck factor: days 45 to 75

Make sure the system does not depend on one person knowing how everything works.

Write down the steps for deploying the product and responding to incidents. Have a second engineer actually ship to production rather than simply reading the documentation. If something important can only be fixed by one person, pair on that area until another engineer can handle it.

At the same time, write an architecture note that matches the numbers and claims in your investor deck. If the deck says the company can support a particular level of growth, the architecture documentation should make it possible to explain how the system is expected to handle that growth.

6. Build the data room and rehearse: days 60 to 90

By the final month, bring the evidence together. The data room should contain the signed IP assignments, SBOM, licence and dependency scan reports, security summary and architecture documentation.

Then test the material before an investor does. Ask an engineer who is not involved in the project to review it without additional context. Have them identify what they would question, what they cannot understand and which documents they would ask to see next.

That rehearsal can expose gaps while there is still time to fix them.

Why the SBOM matters now

The regulatory case for maintaining an SBOM is becoming stronger, particularly for companies selling software into regulated markets.

Executive Order 14028, issued in May 2021, included providing a Software Bill of Materials for software sold to the US government among the practices being pursued to improve software supply-chain security. The US Department of Commerce's SBOM guidance followed with a set of minimum elements that gives companies a practical baseline for what an SBOM should contain.

The European Union has also introduced SBOM requirements through the Cyber Resilience Act. For products with digital elements, the Act requires manufacturers to draw up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies.

The Act's main requirements apply from 11 December 2027, while Article 14's reporting requirements apply from 11 September 2026. The European Commission announced the Act's entry into force in December 2024. These dates matter because the regulatory requirements are being introduced in stages rather than all at once.

The practical point for a founder is simpler than the regulatory timeline: an SBOM is becoming part of the expected evidence around software supply-chain security. Generating one during diligence preparation gives you a useful record of what is actually inside the product.

There is also a difference between awareness of SBOMs and the much broader concept of due diligence. Wikimedia's pageview data recorded 2,844 views of the English Wikipedia article on software bills of materials during the twelve months to August 2026, compared with 86,309 views for its due-diligence article. Pageviews do not measure how many companies actually use SBOMs, so they cannot establish that most founders lack one. They do, however, illustrate how much narrower the topic is in general public interest.

For a founder preparing for a Series A, the better goal is not to guess what other companies have done. It is to make your own technical evidence easy to inspect.

After 90 days, an investor should be able to answer five basic questions without reconstructing the story themselves:

• Who owns the code?
• What third-party software is in it?
• What licence obligations come with that software?
• How does the company identify and respond to security vulnerabilities?
• Can more than one person operate and maintain the system?

If you can answer those questions with documents, scan results and working processes rather than explanations from memory, the technical side of diligence becomes much easier to defend.

How does diligence differ at seed, Series A and acquisition?

The depth of technical diligence generally increases with the legal commitments and financial stakes involved. A standard Y Combinator post-money SAFE contains a knowledge-qualified representation about intellectual property but no specific open-source representation. The NVCA model Series A purchase agreement goes further, with representations covering employee and consultant IP assignments and the use of copyleft code.

Carta reported a median gap of 1.9 years between seed and Series A in Q4 2025. That gives founders time to build the documentation and technical processes that a Series A investor, including the Series A VC firms you are likely pitching, is more likely to examine closely.

Seed: establish ownership early

The Y Combinator post-money SAFE uses a relatively limited IP representation. It states that, to the company's knowledge, the company owns or can obtain the intellectual property necessary for its business as currently conducted and proposed.

That does not mean seed investors have no interest in the codebase. It means the contractual representations are lighter than those commonly found in a later-stage purchase agreement. A founder can use this stage to establish the basics before the level of scrutiny increases.

At minimum, every founder and contributor should have the appropriate IP assignment in place. A first licence scan also gives you an early view of what third-party software is inside the product.

Series A: prove the company controls its technology

The NVCA model purchase agreement goes considerably further. Its representations address whether employees and consultants have assigned their intellectual property and whether the company has embedded GPL, LGPL or other copyleft code in its products.

This is where the preparation from the seed period becomes useful. Instead of trying to reconstruct years of contributor agreements and dependencies during a funding round, you can produce the records and explain the findings.

Carta reported a median Series A valuation of $47.9 million in Q2 2025, a record at the time. It also reported that Series A deal count was down 18% year over year. The same analysis put the median seed-to-Series A interval at 616 days.

The market data does not establish that a particular investor will conduct more diligence because rounds are larger or less numerous. It does show that the financial context of a Series A can be substantially different from an early seed round.

Acquisition: the same questions become transaction evidence

An acquisition can involve a much deeper review because the buyer is evaluating the technology as part of the transaction itself. The exact representations and diligence process depend on the buyer and the deal.

Black Duck's 2026 data provides one indication of how codebase audits are used at this stage. Of the 947 commercial and proprietary codebases in its dataset, 197 came from M&A transactions. Black Duck says these audits are conducted for purposes including M&A transactions, regulatory compliance and internal risk assessment.

There is no equivalent public dataset that gives a reliable acquisition-stage timeline or shows how often particular technical findings delay or change a transaction. It is therefore better to avoid treating acquisition diligence as having a fixed schedule.

What does carry forward is the evidence. A buyer can ask the same basic questions as a Series A investor: who owns the code, what third-party components are present, what licences apply, what vulnerabilities exist and whether the system can be operated without relying on one person.

The difference is that, by acquisition, you ideally should not be creating this evidence for the first time. Your assignments, SBOM, licence scans, security records, runbooks and architecture documentation should already exist and have a history behind them.

That is the real progression:

• Seed: establish ownership and start documenting the codebase.
• Series A: prove that the company controls, understands and can operate its technology.
• Acquisition: demonstrate that those controls have been maintained as an ongoing company process.

Where RocketDevs fits

Technical diligence ultimately comes down to whether an investor can trust what the company says about its technology. Five areas tend to matter most: IP ownership, continuity, open-source licensing, security exposure and whether the architecture can support the company's growth plans.

RocketDevs is most directly relevant to the first two.

Every developer on the RocketDevs bench has completed 6-8 hours of technical assessment and comes from the top 2% of applicants. When a developer is placed with a client, the engagement includes an IP assignment to the client. The developer also works within the client's engineering process and hands over documented work.

That matters for IP ownership because the legal question is not simply whether someone wrote the code. The company needs appropriate documentation showing that the rights to that work belong to the company. Having the right agreement in place from the beginning makes that record easier to maintain as the engineering team grows.

It also matters for continuity. An investor does not want the company's ability to deploy, debug or extend its product to depend entirely on one engineer. A second engineer who understands the codebase, works on important systems and documents what they build gives the company more operational coverage.

RocketDevs does not replace the founder's responsibility for the rest of the diligence process. Open-source licences still need to be reviewed. Vulnerabilities still need to be patched. The architecture still needs to be documented and tested against the company's growth plans. Those are company-level responsibilities.

Where an additional senior engineer can help is turning that preparation into actual engineering work. In the 90-day plan above, a senior developer can help inventory the repositories, run the dependency and licence scans, generate the SBOM, investigate findings, patch vulnerabilities and document deployment and incident-response procedures.

At RocketDevs' senior rate of $30.99/hr, that work can be added to the engineering capacity you already have rather than taking the founder away from fundraising, customers and product decisions. The exact time required will depend on the number of repositories, size of the codebase and number of findings uncovered by the initial scans.

The timing also matters. Technical diligence is easier when the evidence is produced as part of normal engineering work rather than assembled during the final weeks before a funding round. A senior engineer can establish the scanning and documentation process, fix the issues it exposes and leave the company with records that can be maintained after the raise.

You can build a vetted engineering team with RocketDevs and use the 14-day risk-free trial to evaluate the engagement before committing further. The goal is not to outsource diligence itself. It is to add engineering capacity so that the technical work behind your diligence preparation gets done while your existing team keeps shipping.

Conclusion

Technical due diligence is not an exam you suddenly sit for when an investor asks for access to your codebase. By that point, the evidence already exists. The question is whether you have organised it well enough to prove what you know.

At seed, that means getting the basics right. Know who owns the code. Make sure contributors have signed the right agreements. Start tracking your dependencies and licences.

By Series A, the standard is higher. Investors can ask you to demonstrate that the company controls its intellectual property, understands its open-source obligations, responds to security vulnerabilities and has an engineering organisation that can operate the product without depending on one person.

An acquisition can take those questions even further. A buyer may inspect the codebase as an asset they are considering purchasing, which means undocumented assumptions can become transaction problems.

Think of your codebase like a house you are preparing to sell. You do not want to discover on the day of the inspection that the previous owner never transferred the title, the electrical wiring has an undocumented modification and only one person knows how to turn the heating on. You want the paperwork organised, the problems fixed and the important systems documented before the buyer arrives. The same principle applies to software.

A clean technical diligence process gives an investor something more valuable than a clean scan: confidence. They can see:

• Who owns the code
• What is inside the code
• How vulnerabilities are handled
• That more than one engineer can operate the system
• That the architecture described in the pitch deck exists in the product

Most importantly, you do not need to wait for a term sheet to start.

A 90-day preparation plan is enough to turn scattered agreements, repositories and engineering knowledge into a defensible technical record. Start with the ownership gaps that take longest to fix. Build the SBOM. Resolve the licence findings. Patch the vulnerabilities. Reduce the truck factor. Document the architecture. Then put everything somewhere an investor can actually review it.

That work does more than make diligence easier. It makes the company stronger.

When the investor eventually asks to look under the hood, you should not have to hope they like what they find. You should already know what is there, why it is there and who is responsible for it. That is what technical readiness for a Series A really means.

Frequently asked questions

How long does technical due diligence take?

No independent dataset measures it, so every published figure is an estimate from a firm that sells diligence work. CTO on Demand puts it at "One to three weeks for most venture deals; two to six weeks for complex M&A", per its diligence checklist, and CRV describes a formal diligence window of about six weeks after the term sheet. A prepared data room shortens it; a missing assignment lengthens it by however long it takes to find a former contractor.

Do seed investors do technical due diligence?

Rarely in a formal sense, because the standard YC post-money SAFE asks the company for a single knowledge-qualified promise about its intellectual property and nothing about open source. VeryCreatives, a software consultancy, writes that "Technical review now shows up at seed and Series A", per its founder guide, so expect questions even when there is no audit. Treat seed as the cheapest moment to collect assignments, because the contributor list is shortest.

What is an SBOM and do I need one?

An SBOM is "a formal record containing the details and supply chain relationships of various components used in building software", in the words of the US Department of Commerce's 2021 minimum elements. You need one if you sell software to the US government under the practices set by Executive Order 14028 or place products with digital elements on the EU market once the Cyber Resilience Act's main obligations apply on 11 December 2027. Everyone else needs one because it is the output of the licence scan a Series A reviewer will ask for anyway.

Can GPL code in my product kill a deal?

It can turn into a disclosure you must make against the NVCA model representation that the company "has not embedded any open source, copyleft or community source code" in its products, which names the GPL and LGPL. Whether it matters depends on how you ship: GPL obligations attach to distribution, and the AGPL's section 13 extends them to modified versions users reach over a network. Disclose it, explain it, and replace it where the explanation is weak.

Who owns code written by a contractor?

In the US, the contractor does, unless a signed writing transfers it: software is not among the nine categories that can be a commissioned work made for hire under 17 U.S.C. 101, and 17 U.S.C. 204(a) requires a signed writing for any transfer. The US Copyright Office's Circular 30 says that if a commissioned work fails any of its four criteria, "it is not a work made for hire", and UK government guidance says the first owner of a commissioned work is its creator "unless you otherwise agree it in writing", per GOV.UK. This is not legal advice; have counsel check the position where your contractors are based.

What should I fix first if my Series A is 90 days away?

Follow the work in this order:

1. Prove who owns the code: Export your Git contributors and create a simple list of every founder, employee, contractor and other contributor. Match each person to a signed IP assignment. Flag anyone where the agreement is missing, unclear or does not cover the relevant work. Start chasing former contractors immediately because they can take the longest to reach.
2. Scan everything: Run a dependency, licence and vulnerability scan across every repository, including transitive dependencies. Use the results to generate an SBOM in SPDX or CycloneDX. Do not wait until the data room is being assembled to discover what is actually inside the product.
3. Triage the findings: Separate findings that could affect ownership, legal obligations or security from lower-priority engineering issues. Resolve missing licences and material copyleft questions. Patch high and critical vulnerabilities and keep evidence of the fixes.
4. Remove the single point of failure: Identify the systems only one person can deploy, debug or change. Write the runbooks and have a second engineer actually perform the critical tasks. Documentation that nobody has tested is not much protection against a truck-factor problem.
5. Check the story against the product: Take the architecture described in your investor deck and compare it with what is actually running. Make sure claims about scale, infrastructure and engineering capacity can be explained from the current system.
6. Build the evidence folder: Keep the signed assignments, SBOM, scan reports, vulnerability history, security summary, runbooks and architecture documentation together. Give each document a clear owner and keep it updated as the product changes.
7. Rehearse before the investor does: Give the material to an engineer or technical adviser who was not involved in building the system. Ask them to review it as if they were conducting diligence and write down every question they would ask. Fix the gaps you can and prepare clear explanations for the ones you cannot.

The goal is not to make every technical finding disappear. It is to make sure that when an investor finds something, you already know what it is, understand its impact and can show what you are doing about it.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Black Duck, 2026 Open Source Security and Risk Analysis report
• Xu, Gao, Fan, Liu, Liu and Ji, LiDetector: License Incompatibility Detection for Open Source Software, ACM TOSEM
• Sonatype, 2024 State of the Software Supply Chain, scale of open source
• Sonatype, 2026 State of the Software Supply Chain, vulnerability management
• SPDX license-list-data repository, licenses.json, version 3.29.0
• SPDX License List
• ScanCode Toolkit repository
• GitHub API, aboutcode-org/scancode-toolkit
• npm registry downloads API, @cyclonedx/cyclonedx-npm
• US Department of Commerce and NTIA, The Minimum Elements for a Software Bill of Materials, 12 July 2021
• Executive Order 14028, Improving the Nation's Cybersecurity, Federal Register, 17 May 2021
• Regulation (EU) 2024/2847, the Cyber Resilience Act, EUR-Lex
• European Commission, A safer digital future: new cyber rules become law, 10 December 2024
• Wikipedia, Cyber Resilience Act
• Wikimedia pageviews API, Software bill of materials
• Free Software Foundation, GNU Affero General Public License v3
• 17 U.S.C. 106, exclusive rights in copyrighted works, govinfo
• 17 U.S.C. 204, execution of transfers of copyright ownership, govinfo
• 17 U.S.C. 101, definitions including work made for hire, govinfo
• US Copyright Office, Circular 30, Works Made for Hire
• UK Intellectual Property Office, Ownership of copyright works, GOV.UK
• National Venture Capital Association, model Series A stock purchase agreement
• Y Combinator, post-money SAFE, valuation cap only
• Verizon, 2026 Data Breach Investigations Report
• Mandiant, M-Trends 2025, Google Cloud
• Eurostat, security incidents and consequences by size class of enterprise, 2024
• Carta, Peter Walker, Time between startup rounds is finally trending down
• Carta, Kevin Dowd, The new state of Series A fundraising, 19 September 2025
• Avelino, Passos, Hora and Valente, A novel approach for estimating truck factors, ICPC 2016
• Jabrayilzade and colleagues, Bus Factor in Practice, ICSE 2022
• CRV, Series A funding: how to prepare your data room, 16 July 2026
• KORE1, Kris Drouet, Inside technical due diligence, 14 September 2026
• Montague Law, Software startup IP diligence checklist
• VeryCreatives, Ferenc Fekete, Technical due diligence for founders, 23 July 2026
• CTO on Demand, Technical due diligence checklist