Climate hardware: simulation to physical prototyping

The question was whether to spend nearly $50,000 on a physical build immediately or use simulation to pressure-test the design first and risk losing time learning tools instead of building hardware.

That is the real climate hardware prototyping decision. It is not “simulation versus physical testing” in the abstract. It is a trade-off between cash, speed, confidence, and the kind of failure you can still afford to discover. Simulate too little and you pay the physical prototype tax before you understand the product. Simulate too much and you can spend months optimizing a model that was never faithful to the field.

Climate hardware is particularly unforgiving here. A product may need to operate outdoors, under vibration, humidity, temperature swings, inconsistent power, dirty fluids, variable feedstock, or changing grid conditions. The clean assumptions in a CAD file rarely survive all of that.

The strongest teams do not choose one side. They decide which questions belong in software, which require a physical article, and when the evidence is strong enough to move to the next stage.

The physical prototype tax starts earlier than most teams think

Hardware founders often describe their first build as an MVP. In practice, it is frequently a bundle of unresolved questions disguised as a product.

Will the enclosure survive thermal cycling? Can the pump maintain flow when the fluid is contaminated? Does the battery management system behave correctly when the load changes quickly? Will a sensor remain accurate after weeks of condensation? Can the manufacturer hold the tolerances the design assumes? Does the wiring layout create heat or electromagnetic interference that was invisible in the original architecture?

A physical prototype can answer these questions, but it answers them expensively. A 2023 study referenced by IEEE found that prototyping and rework account for approximately 43% of hardware project budgets. That number should not be read as an argument against building. It is an argument against using fabrication as your first analytical tool.

The cost is not only the invoice from the contract manufacturer. It includes:

• Engineering time spent revising parts that should have been challenged earlier.
• Expedited components and low-volume manufacturing premiums.
• New tooling, fixtures, and test equipment.
• Delays while a supplier waits for a corrected drawing or replacement component.
• The opportunity cost of tying up the team in rework instead of field learning.
• Lost credibility with pilot customers when the promised test unit arrives late.

The schedule risk is just as serious. McKinsey has reported that nearly one-third of electronics products miss their original development deadlines, with late-discovered hardware bugs among the primary causes. The IPC’s 2024 global manufacturing brief also reported that more than 60% of hardware teams experienced fabrication delays because early validation was incomplete.

Those figures do not mean every climate hardware company needs a large simulation team. They do mean that “we will find out when we build it” is not a neutral plan. It is a budget and schedule decision.

The first prototype should answer the most expensive unanswered question—not merely prove that the team can assemble the parts.

There is also a psychological trap. Once a team has spent heavily on a physical build, people become reluctant to challenge the underlying concept. The prototype acquires emotional weight. Engineers work around its flaws. Founders protect the launch date. Investors hear that the product is “almost there” because admitting that the architecture needs a pivot feels worse after fabrication than before it.

This is how sunk cost enters product development wearing a safety helmet.

Simulation is most valuable before the design looks finished

Simulation works best when the question is narrow enough to model and consequential enough to matter.

For a climate hardware MVP, that might be:

• Whether a heat exchanger can meet a target thermal performance within the available footprint.
• Whether a structural component will deform under expected loads.
• Whether airflow or fluid flow creates unacceptable pressure losses.
• Whether a power electronics design can respond to fast changes in load.
• Whether a control algorithm remains stable across a range of operating conditions.
• Whether a battery pack or enclosure develops dangerous hot spots.
• Whether a proposed geometry is fundamentally incompatible with the manufacturing process.

Different physics call for different tools. Computational fluid dynamics, or CFD, is useful for fluid movement, airflow, pressure, and heat transfer. Finite element analysis, or FEA, helps examine structural stress, deformation, vibration, and sometimes thermal behavior. Electrical and controls models can test system response before the full electronics stack exists. Hardware-in-the-loop methods place real components inside a simulated environment so the team can evaluate their behavior without exposing the entire system to uncontrolled conditions.

The practical point is less glamorous than the tool names: simulation lets a team change one assumption at a time.

A physical build often changes twenty assumptions at once. You alter the material, the geometry, the supplier, the sensor placement, and the control logic, then discover that the output improved. You may not know why. A virtual model can isolate variables quickly, at least when the model has been constructed responsibly.

That makes simulation especially useful for climate tech startups facing supply-chain constraints. If a complex physical prototype costs around $50,000, the team may not be able to explore multiple architectures in metal, composites, electronics, and molded parts. Software models allow more of that exploration to happen before the purchase order.

But there is a hard limit: simulation is not evidence that the real product works. It is evidence that the product works under the assumptions encoded in the model.

Those assumptions need their own review. A founder with a non-technical background does not need to become a CFD specialist, but they do need to ask the uncomfortable questions:

1. Which inputs are measured, and which are guessed?

2. What operating range does the model cover?

3. Which variables have the greatest effect on the result?

4. Has the model been compared with any physical data?

5. What does the simulation deliberately leave out?

6. What happens if the material, temperature, humidity, or load differs from the nominal case?

7. Which result would change the product architecture rather than merely improve its settings?

A simulation report with colorful contours can create false confidence. A rough model that exposes a fatal pressure, thermal, or structural problem can be enormously valuable. The difference is not visual sophistication. It is whether the model is connected to a decision.

A useful comparison: what each method can actually tell you

The right-hand column is not a consolation prize. Physical testing is where the assumptions meet tolerances, suppliers, weather, operators, and imperfect assembly.

Use simulation to kill bad ideas before you fall in love with them

The most valuable simulation outcome is sometimes a pivot.

That can be emotionally difficult. Climate founders are often attached to the mechanism that made the company feel possible in the first place: a novel reactor geometry, a particular thermal pathway, a custom energy-storage configuration, an elegant control strategy. But customers do not pay for elegance. They pay for reliable tonnes of carbon avoided, energy delivered, water treated, fuel displaced, or operating cost removed.

Early simulation should therefore be treated as a screening process, not a presentation layer.

For a climate hardware MVP, create a small set of decision models before investing in a production-like build. The models do not need to predict every detail. They need to distinguish between:

• Designs that violate basic physical constraints.
• Designs that may work but require unacceptable energy, materials, or maintenance.
• Designs that meet the target only under narrow laboratory conditions.
• Designs that remain plausible across the messy range the customer will actually experience.

This is where a non-technical founder can contribute materially. You are not there to approve mesh density or solver settings. You are there to force the engineering work back toward the business risk.

If the customer requires operation from -10°C to 40°C, a model at room temperature is not enough. If the economics depend on a component lasting five years, a one-hour performance simulation does not address the commercial claim. If the product will be installed by technicians with limited training, a model that assumes perfect assembly is answering the wrong question.

Simulation also changes the conversation with a technical cofounder or development partner. Instead of asking, “Can we build this?” ask, “Which assumptions need validation before we commit to this architecture?” That wording creates room for disagreement without turning every disagreement into a referendum on the founder’s vision.

A practical early-stage sequence looks like this:

1. Define the failure that would force a pivot.

It might be insufficient thermal efficiency, excessive parasitic power, unacceptable structural stress, or a unit economics problem caused by materials and manufacturing.

2. Build the simplest model that can test that failure.

Do not start by recreating the entire product digitally. Model the subsystem that carries the greatest technical or commercial risk.

3. Run sensitivity analysis.

Find out whether the result depends on one optimistic assumption. If a 5% change in flow rate or material conductivity destroys the business case, that matters more than the best-case output.

4. Set a physical test that challenges the model.

The first physical article should not simply confirm the simulation. It should be designed to expose where the model is wrong.

5. Update the model with measured data.

This is where simulation becomes more useful over time. A calibrated model can help prioritize the next build rather than replace it.

The temptation is to buy the most capable hardware simulation tools for startups and treat the license as progress. That is backwards. Start with the decision, then select the level of modeling required. Licensing, training, data preparation, and engineering time can all be substantial. A sophisticated tool used by a team without reliable inputs is an expensive way to produce confident-looking uncertainty.

Power Hardware-in-the-Loop is the bridge when software alone is too clean

Some climate systems are difficult to test safely or economically at full scale. Grid-connected equipment is a good example. A startup developing an inverter, battery system, microgrid controller, or power-conversion product needs to know how the hardware responds to changing voltage, frequency, load, and grid events. A purely virtual model may miss the behavior of the real controller, sensors, switching devices, and protection systems. A full field deployment introduces safety, permitting, and equipment risks.

Power Hardware-in-the-Loop, or PHIL, occupies the useful middle ground.

In a PHIL setup, real power hardware is connected to a simulated environment through power amplifiers and control interfaces. The simulated grid or load changes in real time, while the physical component responds as it would in operation. The response is fed back into the model, creating a controlled loop.

At KIT’s Energy Lab 2.0, PHIL testing has been conducted with amplifiers reaching capacities of up to 1 MVA. A startup will not necessarily have access to that scale, and the point is not to copy a national laboratory. The point is that real-time simulation can test difficult operating conditions without immediately committing to a full physical system in the field.

PHIL can help investigate questions such as:

• How does a controller respond to a sudden load change?
• What happens when the simulated grid frequency moves outside the nominal range?
• Does protection activate when expected, and does it reset safely?
• Can the hardware maintain stable operation when the rest of the system behaves unpredictably?
• Does the control strategy remain robust when sensor delays and communication constraints are included?

This kind of testing is particularly useful before pilot deployment, when the cost of a failure is no longer limited to a damaged prototype. A failed field test can disrupt a customer’s operation, damage equipment, trigger insurance or safety concerns, and make the next pilot much harder to secure.

The trade-off is complexity. PHIL requires specialized facilities, real-time models, power interfaces, instrumentation, and people who understand both the physical device and the simulation environment. It is not a shortcut for every startup. But for power hardware, it can be a disciplined way to move from “the model says it should work” to “the real controller has survived credible operating conditions.”

Physical prototypes remain the final arbiter of reality

Simulation cannot reproduce every property of a manufactured object. Material properties can vary by as much as 15% from nominal datasheet values, and those deviations may matter when a design operates close to its limits. Tolerance stack-up, vibration, humidity, contamination, connector behavior, assembly errors, thermal expansion, and aging all create failure modes that a clean digital model may not reveal.

This is why physical prototyping for climate tech is not the opposite of simulation. It is the test of whether simulation deserves to be trusted.

The physical article should become more representative as the questions change.

An early build may use off-the-shelf parts, temporary fixtures, hand-cut materials, and visible wiring. That is appropriate when the question is whether a mechanism works at all. It is not appropriate for proving that the product can be manufactured, installed, serviced, or certified at scale.

By the time the team reaches design validation, the prototype needs to resemble the intended product in the ways that affect performance and risk. A different material, supplier, coating, seal, connector, or assembly method can invalidate an otherwise successful test.

The most useful physical tests usually fall into four categories:

Performance tests

These establish whether the system delivers the claimed output under defined conditions. For a thermal product, that might mean efficiency across a temperature range. For a water or air treatment device, it may include flow, pressure drop, contaminant loading, and energy consumption. For energy hardware, it may involve dynamic response, power quality, and protection behavior.

Environmental and durability tests

These expose the difference between nominal lab performance and field resilience. Temperature cycling, humidity, vibration, dust, corrosion, ingress, and repeated start-stop cycles can matter more than another round of optimization at room temperature.

Integration tests

A subsystem can work perfectly in isolation and fail when connected to the rest of the product. Sensors may interfere with mechanical packaging. Heat from power electronics may degrade nearby materials. Firmware timing may break under real communication delays. A pump may meet its curve until the plumbing, filter, and fittings are installed.

Manufacturing and service tests

The product must be built and maintained by real people using real processes. Can a technician assemble it without improvising? Are connectors accessible? Can a supplier hold the critical dimension? Does the design require an adhesive cure time that will break the production schedule? Can a worn component be replaced without removing half the machine?

These questions rarely appear in an early simulation because they are not only physics questions. They are operations questions.

A climate hardware development lifecycle that does not confuse milestones with evidence

The Scale For ClimateTech framework separates hardware development into stages: Pre-Engineering Prototype, or Pre-EP/MVP; Engineering Validation Test, or EVT/Alpha; Design Validation Test, or DVT/Beta; and Production Validation Test, or PVT/Pilot.

The labels are useful, but only if the team treats them as evidence gates rather than ceremonial names for increasingly expensive prototypes.

Pre-EP or MVP: prove the core mechanism

At this stage, the goal is not a polished product. It is to establish that the central mechanism can deliver a meaningful result and to identify the assumptions that deserve deeper work.

Use simulation to compare architectures, estimate operating envelopes, and eliminate designs that are physically implausible. Use a deliberately simple physical setup to test the highest-risk mechanism. The build may be ugly. That is fine. An ugly prototype that teaches the team something decisive is doing its job.

The exit question is: Do we have evidence that the core effect is real and worth engineering?

EVT or Alpha: prove the engineering architecture

Now the team begins integrating the actual subsystems. The purpose is to find interactions and engineering failures, not to demonstrate market readiness.

Simulation should be calibrated against measured data wherever possible. Physical tests should explore the operating range, not only the best case. Instrumentation matters because a pass/fail result without diagnostic data can force another expensive build.

The exit question is: Can the architecture meet its critical technical requirements under controlled but credible conditions?

DVT or Beta: prove the design in realistic conditions

This is where environmental variation, enclosure decisions, manufacturing tolerances, user interaction, and serviceability become central. The product should be close enough to the intended design that test results mean something for deployment.

A DVT build is a poor place to discover that the chosen supplier cannot make the critical part consistently. That issue belongs earlier, even if the exact production process is not yet locked.

The exit question is: Does the design remain safe, functional, and maintainable when the conditions stop being kind?

PVT or Pilot: prove the production system

PVT is not simply “make more units.” It tests whether the product and the process can work together. The team should be learning about yield, assembly time, inspection, documentation, packaging, installation, commissioning, and early service events.

Simulation still has a role here. It can help explain field behavior, model edge cases, and prioritize changes. But it should not be used to argue away evidence from pilot units. If five production-intent units show a recurring thermal issue, the model is not the authority. The units are telling you where the model or the design is incomplete.

A successful simulation earns the right to build the next test article. It does not earn the right to skip that article.

How founders should budget the trade-off

The right balance depends on the product, but a few operating rules hold across most climate hardware teams.

First, budget for learning loops rather than one “prototype.” The word suggests a single object. Development is usually a sequence of increasingly representative articles, each tied to a question. A budget that covers only the first build is not a development budget; it is a hope budget.

Second, separate prototype cost from validation cost. A hand-built rig may prove the mechanism. It will not necessarily provide the data required for compliance, durability, manufacturing, or customer deployment. Those are different expenses and should appear separately in the plan.

Third, put uncertainty next to every major technical claim. If the business model assumes a certain efficiency, service interval, lifetime, or throughput, record what is measured, what is simulated, and what is borrowed from a supplier datasheet. The distinction matters when the team decides whether to raise, pivot, or enter a pilot.

Fourth, involve manufacturing earlier than feels comfortable. Simulation can show that a shape works. A manufacturer can tell you that the shape requires a tool, tolerance, material, or process you cannot afford. Those are not downstream details. They can change the architecture.

Finally, do not let a technical milestone outrun the commercial one. A climate product that works in a lab but cannot be installed within the customer’s outage window, maintained by the available workforce, or financed under the buyer’s procurement rules is not ready. The product development lifecycle includes those constraints, even when they do not fit neatly into an engineering dashboard.

For non-technical founders, the most useful operating artifact may be a simple validation register with five columns:

• Claim the team needs to prove.
• Current evidence: simulation, bench test, supplier data, or field data.
• Assumptions that could invalidate it.
• Next test and the decision it will unlock.
• Cost and time if the test fails.

This turns technical uncertainty into something the company can manage. It also makes the emotional side of a pivot less destructive. A pivot is painful when it feels like the team is abandoning the company. It is more manageable when the evidence shows that one architecture has failed and another deserves a test.

The hard-earned lesson

The climate hardware prototyping simulation vs physical testing debate is often framed as a choice between speed and certainty. That is too simple. Simulation can provide speed and expose structural problems early, but only within the boundaries of its assumptions. Physical prototypes provide reality, but they are expensive, slow, and vulnerable to confounding variables.

The practical answer is to use them in sequence and in opposition:

• Simulate to narrow the design space.
• Build the cheapest physical article that can challenge the critical assumptions.
• Measure enough to improve the model.
• Use calibrated simulation to choose the next build.
• Introduce realistic environmental, manufacturing, and integration conditions before making commercial promises.
• Treat every stage—Pre-EP, EVT, DVT, and PVT—as an evidence gate, not a title on a slide.

The founder with one prototype budget was right to hesitate before fabrication. But the answer was not to stay virtual. The team modeled the highest-risk behavior, built a simpler test rig, found a failure in the original architecture, and changed course before committing to the expensive enclosure and production-intent components.

That is what resilience looks like in hardware. Not avoiding failure. Making sure the failure arrives while it is still affordable, interpretable, and useful.