Why Climate Tech Hardware Companies Are Finally Taking Systems Engineering Seriously

Electrolyzers, direct air capture systems, grid-scale batteries, and industrial heat pumps are transitioning from demonstration-scale curiosity to commercially deployed infrastructure. That transition is forcing a discipline on the sector that should have arrived earlier: systems engineering.

The pattern is familiar to anyone who has watched a technology mature. In the lab and at pilot scale, individual subsystem performance is the only metric that matters. Can we hit the efficiency target? Can we demonstrate the reaction chemistry? Can we show that the stack doesn’t degrade in three months? These are subsystem questions, and they get answered with subsystem thinking.

Commercial production asks different questions. Can we manufacture this at consistent quality across 500 units? Can we guarantee a 20-year operating life in a salt-laden coastal environment? Can our electrolyzer stack handle the variable power input that comes from co-location with wind generation? Can we trace every performance requirement to a specific design decision and test result? These are systems questions, and they require systems thinking.

What’s Actually Driving the Urgency

The climate tech hardware sector has a specific problem that makes systems engineering not just valuable but existential: the cost and performance targets that define project viability are extremely tight, and they do not move.

When a green hydrogen project underwrites a 25-year offtake agreement at $2.50/kg, every component of the electrolyzer’s levelized cost of production — capital cost, efficiency, stack lifetime, maintenance interval, degradation rate — has to land within a narrow band. Miss the stack lifetime target by 30%, and the project economics collapse. Miss the power consumption target by 15%, and the hydrogen you’re selling costs more to produce than the contract price.

This is structurally different from consumer electronics, where you can recover from a mediocre first-generation product with a better second generation. It’s also different from aerospace and defense, where cost overruns are painful but programs survive. In climate tech hardware, failing to hit cost and performance targets at commercial scale means the technology doesn’t get deployed — and that’s a binary outcome.

The implication is that engineering rigor isn’t a quality-of-life improvement for climate tech hardware companies. It’s the mechanism by which they stay viable.

The Interface Complexity Problem

Climate tech hardware systems are architecturally complex in ways that catch engineering teams off guard. The complexity isn’t in any individual subsystem — it’s in the interfaces between subsystems and between the product and its operating environment.

Consider a proton exchange membrane electrolyzer intended for co-location with a utility-scale solar installation. The electrolyzer stack itself operates at stable DC power input with tight voltage and current tolerances. The solar array delivers power that varies continuously with cloud cover, temperature, and time of day. Between those two systems sit power electronics — a DC-DC converter and a rectifier — plus a control system that manages ramp rates to protect membrane lifetime.

Add water treatment on the feed side (the stack is intolerant of dissolved minerals and organic contaminants), hydrogen compression and purification on the output side, and a thermal management system that handles waste heat from the electrochemical reaction. Each of these is a subsystem with its own interface requirements, failure modes, and performance envelope.

Now consider that the electrolyzer may be sited in a location with 90% relative humidity, ambient temperatures ranging from -20°C to 45°C, and a requirement to restart from cold within 30 minutes. None of these are stack-level requirements. They are system-level requirements, and they propagate down into specific design constraints on every subsystem.

Aerospace and defense engineering teams handle this kind of complexity through rigorous interface control. Interface Control Documents (ICDs) define every physical, electrical, data, thermal, and fluid interface between subsystems. Requirements are allocated from the system level down to subsystem and component levels, and that allocation is traceable. When something changes — a supplier changes a connector, a customer changes a duty cycle requirement — the impact of that change propagates through the requirements structure automatically.

Most climate tech hardware companies entering commercial scale do not have this. They have spreadsheets, PDFs, and institutional knowledge held by senior engineers.

What Aerospace and Defense Learned the Hard Way

The aerospace and defense industries didn’t adopt systems engineering because it sounded like good practice. They adopted it because the alternative produced disasters — projects that were late, over budget, and in some cases catastrophically unsafe. The discipline codified in standards like MIL-STD-499, NASA/SP-2016-6105 (the Systems Engineering Handbook), and ARP4754A emerged from decades of failures that were ultimately traceable to requirements problems: requirements that were ambiguous, requirements that were missing, requirements that changed without the change being propagated, and requirements that were never verified.

The automotive industry went through a parallel evolution, driven by safety-critical electronic systems and the complexity of vehicle architectures that now involve dozens of ECUs, thousands of software requirements, and functional safety obligations under ISO 26262. AUTOSAR, ASPICE, and the broader automotive systems engineering ecosystem exist because managing that complexity by spreadsheet produced vehicles with expensive, embarrassing, and occasionally fatal defects.

Climate tech hardware is not aerospace, and it should not pretend to be. The regulatory environment is different, the certification requirements are different, and the program durations are different. Importing a full aerospace systems engineering process into a 50-person electrolyzer company would be counterproductive.

But the core principles transfer directly:

• Requirements must be complete, unambiguous, and allocated. You cannot manage what you cannot specify.
• Interfaces must be formally defined and controlled. Informal interface agreements fail when teams grow, when suppliers change, and when designs evolve.
• Verification must be planned from the beginning. V&V that is bolted on at the end of development costs more and catches problems too late to fix cheaply.
• Changes must be managed. Every requirements change has downstream cost implications. Those implications need to be visible before the change is approved.

The Direct Air Capture Case

Direct air capture (DAC) systems make the interface complexity argument more concrete. A DAC system based on solid sorbent technology involves a contactor that exposes sorbent material to ambient air, a regeneration system that drives off captured CO₂ using heat, a compression and purification train that brings captured CO₂ to pipeline or sequestration specifications, and a thermal management system that integrates waste heat and external heat input.

Each of these subsystems has performance requirements that are interdependent. The regeneration temperature affects sorbent lifetime, which affects the operating cost assumption in the project economics. The contactor pressure drop affects the parasitic power load from fans, which affects the net energy penalty of the system, which is a primary metric in the DOE cost targets that govern project funding.

A change to regeneration temperature — perhaps to reduce sorbent degradation — propagates into thermal system sizing, heat exchanger specifications, insulation requirements, utility specifications, and ultimately into project economics. Without a requirements management system that traces these relationships, that change gets made, the implications get missed, and the discrepancy between modeled and actual performance shows up during commissioning. At that point, fixes are expensive.

First-Generation Energy, Heirloom, and other DAC developers are building systems where this kind of interconnection is the rule, not the exception. The engineering challenge is not primarily chemical — the chemistry is understood. The challenge is integrating that chemistry into a deployable, manufacturable, maintainable system that hits a cost target.

Grid-Scale Batteries and the Reliability Problem

Grid-scale battery systems — primarily lithium iron phosphate (LFP) systems in the 100 MWh to multi-GWh range — present a slightly different version of the same challenge. The reliability requirements for grid-scale storage are set by grid operator contracts and capacity market obligations. A battery system that is unavailable when it was contracted to provide frequency regulation is generating financial penalties, not revenue.

Reliability engineering at the system level requires understanding failure modes, failure rates, and the maintenance strategies needed to keep availability above contractual minimums. That’s a reliability block diagram problem, a FMEA problem, and a spare parts strategy problem — all of which require a defined system architecture and allocated reliability requirements before you can solve them.

Battery system integrators who have come from the power electronics or software side of the industry often treat reliability as an emergent property: build it, deploy it, find out what breaks, fix it. At pilot scale with one or two systems, that approach is survivable. At commercial scale with 50 deployed systems and 20-year warranty obligations, it’s financially ruinous.

The requirement to specify system availability targets, allocate those targets to subsystem reliability budgets, and design both the hardware and the maintenance strategy to hit those budgets is exactly what systems engineering provides.

How Modern Tools Are Lowering the Barrier

One reason climate tech hardware companies have been slow to adopt systems engineering discipline is the tooling. The dominant requirements management tools in aerospace and defense — IBM DOORS, DOORS Next, Siemens Polarion — were built for large programs with dedicated systems engineers and substantial IT infrastructure. They carry significant licensing costs, steep learning curves, and implementation timelines measured in months. For a 40-person hardware startup that needs to start managing requirements better next quarter, they’re not practical entry points.

The automotive sector has partially solved this with tools like Jama Connect and Codebeamer, which are more accessible but still carry the conceptual overhead of traditional requirements management paradigms — primarily document-centric approaches that scale poorly when interface complexity increases.

The more relevant development for climate tech companies is the emergence of AI-native tools that model requirements and their relationships as a connected graph rather than a document hierarchy. Flow Engineering, built specifically for hardware and systems engineering teams, represents this approach: requirements, interfaces, subsystems, and verification activities are nodes in a graph, with relationships between them that allow change impact analysis and traceability to propagate automatically. When a system-level requirement changes, the tool can surface which subsystem requirements are affected, which interface specifications need review, and which verification activities need to be re-examined.

For a climate tech hardware team that is starting from spreadsheets, this kind of tool represents a practical on-ramp to systems engineering rigor without requiring the process overhead of a defense prime. The AI assistance in tools like Flow Engineering is particularly relevant for teams that don’t have experienced systems engineers on staff — requirements quality analysis, consistency checking, and interface completeness assessment are capabilities that help small teams punch above their weight.

Practical Starting Points for Climate Tech Teams

The gap between current practice and mature systems engineering is not closed in one step. The following sequence is practical for companies in the demonstration-to-commercial transition:

Start with system-level requirements before subsystem design. The most common failure mode is designing subsystems and then writing requirements to match the design. Requirements should drive design, not describe it. A single working session that asks “what does this system have to do, in what environment, with what reliability, at what cost?” produces a starting set that is worth more than any retrospective requirements exercise.

Define interfaces explicitly and early. For every interface between major subsystems, produce a document — even a simple one — that specifies what crosses the interface: power levels and tolerances, fluid pressures and temperatures, data signals and protocols, physical connection types. This becomes the reference that prevents interface mismatches from surviving to integration.

Plan verification before you freeze the design. For each requirement, ask how you will verify it before the system ships. If you can’t answer that question, either the requirement is wrong or the design is wrong. This exercise frequently surfaces requirements that are untestable as written and requirements that require test infrastructure that takes months to procure.

Manage requirements change explicitly. When a requirement changes — and requirements always change — the change should be recorded, the reason should be documented, and the downstream impact should be assessed. A simple change log is better than nothing. A requirements management tool with impact analysis is better than a change log.

Honest Assessment

The climate tech hardware sector is early in its systems engineering maturity. The companies doing this well are typically those that have hired engineers from aerospace, defense, or automotive backgrounds and given them organizational support to build process alongside hardware. The companies doing it poorly are producing demonstrations that work but can’t scale, products that don’t meet field conditions, and projects whose economics collapse when actual performance meets the contractual model.

The discipline exists. The tools exist. The knowledge transfer from mature sectors is straightforward. What the climate tech hardware sector needs to internalize is that requirements rigor is not bureaucracy imposed on good engineering — it is the mechanism by which good engineering produces the specific outcomes that make these technologies viable at commercial scale.

The planet does not grade on a curve. Neither do offtake agreements.