Technical due diligence in climate tech: what VCs miss when they only read the deck

tl;dr. Climate tech due diligence is not the same as SaaS due diligence. The code base is usually fine. The real risks live in hardware dependencies, certification timelines, regulated market access, grid partnerships, and field economics. I have built and operated this kind of system, and when I look at companies in the space, the same five things carry the real risk. Here they are.

A clean GitHub repo is the least interesting thing about a climate tech company.

I say that as someone who reads code for a living. When a fund asks me to run technical due diligence on a SaaS company, the code base is genuinely most of the story. Architecture, test coverage, security posture, key-person risk in the engineering team. Get those right and you have a reasonable picture of the technical risk. Climate tech does not work that way, and the diligence frameworks that funds reuse from their SaaS deals consistently miss the risks that actually kill these companies.

Why SaaS frameworks underweight climate risk

The reason is structural. A SaaS company's risk is almost entirely in software, because software is almost the entire product. A climate tech company's product is usually a system that spans software, hardware, a regulated market, and a physical deployment, and the software is often the least risky part of that system. When you point a SaaS diligence framework at a climate company, you do a thorough job of evaluating the safest twenty percent of the risk and you barely look at the other eighty.

The classic failure mode looks like this. A fund gets comfortable with a hardware-dependent energy company because the code looks great, and then the company misses its numbers for a year because a certification body takes far longer than the founders assumed. The code had nothing to do with it. The code was never the risk.

The five axes that actually matter

There are five risk axes I look at first in any climate tech company, roughly in the order that they tend to be fatal.

The first is the hardware supply chain. If the product depends on hardware, whether that is sensors, gateways, inverters, or custom electronics, you need to understand where it comes from, how many suppliers exist, what the lead times are, and what happens when one supplier discontinues a component. A surprising number of climate hardware companies have a single point of failure in a chip or a module that they do not control and have not designed around. The supply-shocked years made this much worse, and the recovery has been uneven, so the question is live again in 2026 in a way it briefly stopped being.

The second is the certification path. Anything that touches the grid, the building, or the home has to be certified, and certification timelines are long, expensive, and outside the company's control. The question I ask is not "are you certified" but "what is the longest certification you have not yet started, and what is your evidence for how long it will take." Founders routinely and badly underestimate this, and the gap between their plan and reality is often the same as the gap between their projected and actual revenue.

The third is regulatory market entry. Energy markets are regulated differently in every country, and a product that works in Germany may be unsellable in Poland or France without significant rework. I want to understand which markets the company can actually sell into today, which ones require regulatory work first, and how long that work takes. A company with a great product and a real three-country addressable market is a very different investment than the founders' "all of Europe" slide suggests.

The fourth is grid and utility partnerships. Many climate tech business models depend on integrating with a grid operator, a utility, or a balancing market, and those relationships move at the speed of large regulated institutions, which is to say slowly. The question is whether the company has a real signed relationship, a running pilot, or just a friendly conversation with someone who works at the DSO. The difference between those three is frequently measured in years, and the founders will tend to present all three as if they were the same thing.

The fifth is unit economics under scaling. Hardware-touching businesses have unit economics that change as they scale, sometimes for the better and sometimes much worse. Installation cost, field maintenance, hardware refresh cycles, and support load all scale with the fleet, and a company that looks profitable at a thousand units can be deeply unprofitable at a hundred thousand if the field economics are wrong. SaaS diligence rarely models field maintenance, because SaaS does not have any, so this is the axis that SaaS-trained diligence misses most completely.

The interview that matters most

The single most valuable interview in a climate tech diligence is not with the CTO. It is with whoever owns the field deployment.

The CTO will tell you about the architecture, and the architecture is usually fine. The person who owns deployment will tell you what actually happens when a unit goes into a real building, in a real basement, wired by a real electrician who has never seen this product before. That is where the truth lives. I want to know the installation success rate, the average time per install, the most common failure modes in the field, and the support ticket volume per unit per month. Those numbers tell me more about whether this company can scale than any architecture diagram ever will.

If a company cannot answer those questions with real data, it almost always means they have not deployed enough units to know, which is itself the finding, and a more important one than anything in the code.

Red flags that look like green flags

Some of the most dangerous signals in climate tech diligence look like green flags to a SaaS-trained eye.

Too much architecture documentation is one. A pre-revenue company with a beautifully documented microservices platform is usually a company that has spent its scarce engineering time on the wrong thing. In hardware-touching businesses the constraint is almost never the elegance of the cloud architecture, and a team that over-invested there has usually under-invested in the field, where the real risk lives.

An internal "platform" before there is a product is another. When a small team tells me they have built a platform that will let them launch many products quickly, I get nervous, because platforms are what companies build when they are avoiding the harder work of shipping one product that actually works. The platform is a tell, not a moat.

An ML team without a deployment story is the third. Climate and energy companies love to talk about their forecasting models and their optimization algorithms, and the models are often genuinely good. The question is whether those models are running in production, controlling real assets, and being measured against real outcomes, or whether they are notebooks that produce impressive backtests. The gap between a good model and a deployed model is the gap that matters, and in this sector it is wide and frequently hidden.

What I deliver

A climate tech diligence from me takes about two weeks and produces three things.

A written report that a non-technical partner can read and act on, structured around the five risk axes, with each risk rated and explained in plain language. A set of founder and team calls, including the deployment interview, that I run and summarize. And a 30-60-90 risk register, which is usually the document the partner actually wants, listing the specific things to verify, fix, or monitor in the first three months after the investment if the deal goes ahead.

The report is not a yes or a no. That decision is the fund's, and it depends on price, portfolio fit, and conviction that I do not have and should not pretend to. What I provide is an accurate map of the technical and operational risk, written by someone who has actually built and shipped this kind of system, so that the fund's yes or no is an informed one rather than a comfortable one.

The short version

Climate tech diligence is mostly not about the code. The code is the safe part. The risk lives in the hardware supply chain, the certification path, the regulatory market access, the grid relationships, and the field economics, and a diligence process that does not look hard at all five is handing the fund false comfort dressed up as rigor.

I take on a small number of these engagements for funds investing in climate, energy, and IoT companies, and the work draws directly on building this kind of system at Pstryk rather than just reading about it. If you have a deal in this space and want a technical diligence from someone who has held the pager, the details are on the consulting page.