Technical due diligence for VC portfolio companies

We review software and we also build it. The review and the repair use the same skill: reading a codebase closely enough to say what is actually there, then doing something about it. Technical due diligence answers one question for an investor: is the technology behind this company worth the price being paid for it. That means looking past the pitch deck and into the actual codebase, the actual team, and the actual risk of what happens after the money is invested. Here is what we keep seeing: the demo works, the deck is clean, and nobody has asked who wrote the code or what breaks first at ten times the current usage.

What does technical due diligence check?

A technical due diligence review for a VC or PE deal covers four areas: system architecture, code quality, engineering team strength, and delivery risk. The goal is a plain-language answer to whether the product can scale, whether it can be maintained without the original builders, and whether the roadmap the founders are pitching is realistic given what actually exists today.

Notice what that list does not include. It is not a security audit, a full penetration test, or a line-by-line code review. Those have their place, but they answer different questions and they cost more time than most deals allow. The point of diligence is to measure risk so it is included in the price, not to certify perfection. In our work, the most useful output is not a long report. It is a short call where an investor can ask "so what actually worries you" and get an honest answer.

Architecture: will it keep working as the company grows

A product built to work in a demo and a product built to handle real customer usage are not the same thing. Reviewers look at how the system is structured, where the slowest parts will cause problems first, and whether basic decisions around data, security, and scaling were made deliberately or skipped under deadline pressure.

What we actually follow is the path of a single request. Where does it query the database, how many times, and is that number growing with each new customer or staying flat. A system where every page load runs ten queries against one shared table is fine at a hundred users and painful at a hundred thousand. That is not a reason to reject a deal. Almost every early product has a slow step like this, because the founders were right to release first and optimize later. The question for an investor is different: is the fix a two-week job or a rebuild, and does the team know which one it is.

We also look for the decisions that are expensive to reverse. A poor choice of hosting provider can be replaced in a two-week work cycle. A data model that mixed customer records together with no clean way to separate them is a more serious problem, especially for a company that will later need to sell to enterprise buyers who ask about data isolation. In our work, the architecture review is less about finding flaws and more about sorting them into "cheap to fix" and "structural." Investors can accept a long list of the first kind. It is the second kind that changes the price.

Code quality: can someone else maintain this

Code that only one person understands is a liability, not an asset. A thorough review checks whether the codebase has reasonable structure, test coverage, and documentation, or whether critical logic is understood by only one engineer. This matters most right after a deal closes, when the team composition often changes.

Test coverage is the signal people check first, and it is useful, but a raw percentage is misleading as often as it is accurate. A codebase can report high coverage and still have no test on the one payment flow that actually earns revenue. So we read what the tests protect, not just how many there are. The better signal is often less obvious: can a new engineer clone the repository, follow the setup notes, and get the product running locally in an afternoon. When the answer is no, and it frequently is, that same difficulty will slow every hire the company makes for the next two years.

There is a newer problem here worth naming. More early codebases now contain large amounts of AI-generated code, and that changes what "only one engineer understands it" means. The code may run and look tidy, yet no human on the team can fully explain why a given module does what it does. That is a maintainability risk even when a single founder has not left, because the knowledge was never really there to begin with. We check for it by asking the team to explain to us the parts of the system they trust least. The honest teams have a clear answer. The answer itself is not the worry. Not having one is.

Team: who actually does the work

Due diligence should identify who on the engineering team does the real work, who reviews it, and how dependent the company is on any single person. A team with one strong technical co-founder and no other experienced engineers has a different level of risk than a team with several senior engineers who can each own a critical system.

The version-control history shows this better than any org chart. When most meaningful commits over the last year come from one account, the company has a key-person risk that no term sheet mentions. That is not always a reason to reject the deal. Plenty of strong companies depend on one exceptional builder in the early days. But an investor should know it, include it in the price, and plan for it, because the plan after closing usually involves that person taking on a bigger role, not a smaller one.

We also look at how work moves through the team. Is there code review, or does everything go straight to production. Is there a way to roll back a bad release, or does a failure mean a rushed, unplanned fix. These are not signs of a mature process for its own sake. They are the difference between a team that can add its next five hires without problems and one that will slow down as it grows. In our work, the healthiest early teams are not the ones with the most process. They are the ones who can explain, in one or two sentences, exactly what happens when something breaks at 2am.

Delivery risk: is the roadmap realistic

The roadmap in a pitch deck is a plan. A technical review checks that plan against the team's actual track record and the codebase's actual state, so an investor knows whether the next twelve months of promised features are achievable or optimistic.

The gap we see most often is between the roadmap and the existing system it depends on. A deck promises three major features and an enterprise tier by year end, but the current system cannot support more than one customer's data cleanly, or has no way to add user permissions without touching every screen. The features are not impossible. They just depend on work that is not in the plan and not in the timeline. A good review makes that hidden work visible, so the investor is pricing the real roadmap rather than the one in the deck.

The careful assessment is usually somewhere in the middle. Rarely is a roadmap completely unrealistic, and rarely is it free of risk. What an investor needs is the honest breakdown: which promised features are straightforward given the team and the code, which ones carry real technical unknowns, and which ones silently assume a second engineering team the company has not hired yet.

How Reveneau runs this review

We assess architecture, code quality, team, and delivery risk, and give you a plain-language assessment with the tradeoffs that matter, sized to your deal. None of this requires a six-week audit. For most early-stage deals a focused review is finished in days, not weeks, and it is sized to the investment. A seed round and a growth round deserve different depth, and paying for a deep audit on a small deal is its own kind of waste.

We also work with portfolio companies after the deal closes, adding senior teams where a company needs to act quickly on what the review found. That is the part investors tend to value most. A review that only produces a list of problems leaves the hard part undone. Being able to follow it with people who can actually fix the structural issues, or add experienced engineers to support a single founder, turns the finding into progress. See how we support VC and private equity portfolios end to end.

The same kind of evaluation applies before a hiring decision, not just an investment one. See how to choose the right external development team for the founder-side version of this review.

The best diligence does not try to prove the company is perfect. It tells you, in plain words, exactly what you are buying and what it will take to grow it.

Related guide: Technical due diligence for investors.

One area we now assess as standard: how much of the codebase was generated, and what review process was in place when it was. We ask because it is the fastest-changing risk factor in software right now, and because the answer is genuinely neutral. Generated code is not a negative sign for a company. Generated code that nobody read is a different thing, and it shows up in diligence as a codebase the team cannot fully explain. We are direct about our own position here too: we write all of our code this way, which is part of why we know where to look.