A build partner for the companies you believe in.

When you look at a company before an investment, the technical side is often the hardest to judge. Financials and market size have clear numbers. The software, the team, and the way they release software do not. Technical due diligence gives you that missing assessment, so you can commit with a clear view of what you are buying and what it will take to grow it.

What technical due diligence checks

Technical due diligence is a structured review of the technology behind a company. It goes beyond the demo and checks the parts that decide whether the product can grow and keep working under load.

We check four main areas:

• Architecture. How the system is put together, whether it can handle more users, and where it will have problems first. We look for single points of failure, heavy reliance on one vendor, and design choices that will be expensive to reverse later.
• Code quality. How the code is written, tested, and documented. Clean, tested code is cheaper to change. Disorganized code with no tests slows every future release and hides bugs.
• Team. Who wrote the system, who understands it now, and how much knowledge only one or two people have. A strong product built by people who are about to leave is a real risk.
• Delivery risk. How the team plans, builds, and releases. We look at release frequency, how often things break, and how long fixes take. This tells us whether the company can keep its promises to customers.

We also review security, data handling, and any legal exposure in the code, such as open-source licenses that could cause problems in a later sale. Each area is scored against what the deal actually needs. A company raising a small round to prove an idea does not need the same maturity as one you plan to scale to millions of users, so we set the standard to match your investment thesis rather than a generic checklist.

What this tells an investor

The point of technical due diligence is not to produce a long list of complaints. It is to answer the questions that change your decision.

You want to know: Is the product real, or does it depend on manual work that customers do not see? Can it serve ten times the current customers without a full rebuild? How much money and time will the next two years of engineering actually cost? Are there hidden problems, such as a security weakness or a dependence on one engineer, that could hurt the value after you invest?

A good report answers these in plain language, with evidence. It separates small issues you can ignore from the few that should affect the price, the terms, or the plan for the first year. It also gives you a fair view of strengths, so you do not reject a solid company because one part looked messy at first.

For more detail on how we run this for portfolio companies, see our note on technical due diligence for VC portfolio companies.

How AI ambition should be assessed realistically

Many companies now put artificial intelligence at the center of their pitch. Some of that is real. Some of it is a plan that will not work. Diligence has to tell the difference, because the gap between the two is wide.

The evidence here is discouraging. RAND's 2024 study on why AI projects fail found that more than 80 percent of AI projects fail, about twice the rate of other technology projects, and the main reason is not the technology. It is that teams build the wrong thing because they misunderstand the problem they are solving. So when we assess an AI roadmap, we do not just check whether the models work. We check whether the team has framed a real problem, whether they have the data to solve it, and whether the promised feature depends on results no one can guarantee yet.

This matters for valuation. A company priced on AI promises it cannot deliver is a company priced too high. We flag where the AI is doing genuine work today, where it is still a research experiment, and what would have to be true for the roadmap to succeed. If you want to understand how we build AI systems that reach production rather than stop at the demo, see our AI development work.

How we support portfolio companies after a deal

Diligence ends when the deal closes, but the technical work does not. Most of the value you paid for depends on what the company builds next. This is where a senior team can change the outcome.

After close, we act as an engineering partner for the companies in your portfolio. That can mean helping a founder set up a proper release process, adding senior engineers to a team that has too much work, or taking on a hard project the internal team does not have the experience to finish. We are used to joining an existing codebase, learning it quickly, and releasing work without a long learning period. Our custom software development work is built around exactly this: joining a real system and improving it.

Some portfolio companies carry a lower tolerance for error than most, because a mistake in the software is a mistake in someone's finances or someone's care. Our fintech software development work is built around the accuracy-and-speed tension financial data demands, and our healthcare software development work is built around getting the right clinical data in front of a care team fast enough to matter. Both start from the same principle as the rest of our portfolio support: build the right thing, with senior people who stay accountable for it.

The goal is simple. Turn the plan you approved during diligence into working software, on a schedule you can report to your own investors. Because the same team that ran the review can do the build, the plan does not lose detail as it passes from one firm to the next. We already know where the weak points are, so the first weeks go into the work that increases value, not into learning the codebase from the beginning.

Why fast results matter after close

Time starts counting the day the deal closes. Every month of slow delivery is a month the company is not growing enough to justify the price you paid. So the pressure after a deal is often to move faster, and the common instinct is to hire more engineers quickly.

That instinct can make things worse. One of the oldest lessons in software is still true: adding people to a late project makes it later. New engineers need to be taught the system, and the people teaching them stop building while they do it. So a company with a delivery problem cannot fix it by hiring alone. It usually has a process problem underneath, and more people make the slowest step worse before it gets better.

This is why our diligence looks closely at team and process, not only at how many engineers a company has. And it is why our support after close often starts with fixing how work moves through the team, not just adding people. A small, senior team that releases every week will do better than a large team that releases every quarter. Fast results come from removing what blocks the work, then adding the right people in the right order.

For larger portfolio companies with more teams and systems, our enterprise engagements bring the same discipline at a bigger scale.

Working with us

We built Reveneau to be the technical partner investors call when they need a clear assessment before a deal and engineering capacity after it. The same people who review the code can help improve it, so nothing is lost when work passes between one firm's report and another team's build.

Before you commit, we give you an honest picture of what you are buying. After you commit, we help the company reach the value you saw. Both jobs need engineers who have released real products and can tell the difference between a small mess and a serious risk. That is the work we do.

Five guides cover the work in detail, written for the people who run it. Technical due diligence is the full method, with a report template and a questionnaire you can copy. AI startup due diligence covers what changes when the target's product, or its codebase, is built on AI. Angel investor technical due diligence is written for a non-technical angel with an hour to spend. Technology after the deal covers the first 100 days, integrations, carve-outs and reporting to the fund. And preparing for technical due diligence is the page to send a founder before the review starts.

References

• RAND (2024), Root Causes of Failure for AI Projects. https://www.rand.org/pubs/research_reports/RRA2680-1.html. Used for the finding that more than 80 percent of AI projects fail, about twice the rate of other IT projects, mostly because teams misunderstand the problem rather than the technology.
• Brooks's Law, from The Mythical Man-Month (1975). https://en.wikipedia.org/wiki/Brooks%27s_law. Used for the point that adding people to a late project makes it later, so a delivery problem cannot be fixed by hiring alone.