Climate hardware MVP: a five-stage prototyping project

Her board wanted her to skip the validation stage entirely and go straight from the benchtop prototype to a small production run. The argument was simple: the customer was ready, the commercial commitment looked promising, and every month spent on internal engineering testing was a month the competitor might use to catch up.

The letter of intent was not a signed contract. That distinction mattered, even if the board was treating it as a firm order.

She almost did it. Then she called me, and we walked through what skipping Engineering Validation Testing (EVT) and Design Validation Testing (DVT) actually costs in climate hardware, not in software. The number that mattered wasn't only the test budget. It was the time you can lose when a pilot unit fails in the field, the design partner is no longer willing to carry the project, and you're back at square one while your seed runway burns.

This is the trade-off nobody puts in the pitch deck: climate hardware doesn't fail fast. It fails slowly, expensively, and often in ways that force you to repeat work you thought you had already completed. So if you're a non-technical founder staring at a slide that says "MVP," and you're tempted to treat hardware development like a software sprint — don't. The five-stage model is useful because it gives the work a sequence and a set of questions. In practice, though, teams loop back between stages constantly. A failed DVT test can send you back to Alpha engineering; a supplier problem during PVT can reopen EVT work.

The goal is not to move through five gates without looking back. The goal is to learn what each gate is supposed to teach you before the cost of learning multiplies.

Stage one: Proof-of-Concept and the Pre-Engineering Prototype

The first stage is the messiest, and that's the point. You're not building a product. You're testing a hypothesis. The question isn't "does this work?" — it's "is the core scientific mechanism even real?"

For a carbon capture startup, that might mean a benchtop reactor the size of a coffee mug. For a battery chemistry play, it's coin cells in a glovebox. For an ag-climate sensing company, it could be a strip of off-the-shelf sensors wired to a Raspberry Pi on a lab bench. The physical form changes by category, but the logic is the same: isolate the mechanism that carries the most technical risk and test that mechanism directly.

What matters at this stage is what I call killer-assumption testing. Every climate hardware product has one or two scientific bets that, if wrong, can kill the whole company. The Pre-Engineering Prototype (Pre-EP) is where you find out if your bet is wrong, cheaply. Use simulations. Use off-the-shelf parts. Use whatever a graduate student in a lab could assemble over a weekend. The temptation to over-engineer here is enormous, and it's where founders bleed seed capital before they even know what they're building.

A useful Pre-EP experiment should make the next decision clearer. It may not resemble the eventual product, but it should tell you something that matters:

• whether the reaction, conversion, storage, sensing, or control mechanism works at all;
• which operating conditions make the mechanism fail;
• whether the key performance variable is stable enough to measure repeatedly;
• what must be controlled in later prototypes, and what is merely a presentation detail;
• whether the mechanism can plausibly be connected to a product that customers can operate and maintain.

This is also where measurement discipline starts. A single impressive result is not a validated mechanism. You need to know how the result was produced, what the inputs were, which variables were held constant, and whether another person can reproduce it. A climate hardware company can spend months arguing about industrial design while the underlying test data is still too thin to support a scale-up decision.

The honest trade-off: this stage looks embarrassingly unpolished. Investors walking into your lab will not be impressed. Procurement teams won't return your calls. That's fine. You're not selling yet. You're killing assumptions — and the resilience you build here is in the discipline of learning fast, not shipping fast.

The mistake is not having a rough prototype. The mistake is allowing a rough prototype to acquire the status of a product because it has a housing, a logo, and a customer presentation.

Stage two: Alpha prototypes and internal engineering validation

Once your Pre-EP gives you confidence that the core mechanism is real, you move into the Alpha Prototype — sometimes called the Engineering Prototype. This is the first version of your product that is actually intended to do the job in a controlled environment.

The shift is subtle but important. In the POC, you're asking, "Is the science real?" In the Alpha, you're asking, "Can we engineer something that does this on purpose?"

For a thermal storage company, the Alpha might be a single cell running through charge-discharge cycles on a bench. For an electrified industrial heat startup, it's a single reactor chamber connected to a controlled power supply. For a sensing company, it might be an integrated node with its own enclosure, firmware, power system, calibration routine, and communications pathway — even if every one of those elements is still provisional.

The Alpha lives in your lab, or perhaps in a partner's facility. It does not yet live in the field. It breaks, you fix it, you run it again. That's the job.

This is where engineering reality begins to push back against scientific optimism. Thermal management, seals, connectors, corrosion, calibration drift, software faults, electromagnetic interference, maintenance access, and operator workflow start to matter. A mechanism can perform well in isolation and still become unreliable when it is connected to pumps, valves, sensors, power electronics, controls, or a human being who was not present during the design review.

The Alpha stage should produce more than a working demonstration. It should produce a clearer architecture. You need to learn which components are central to performance, which are temporary substitutes, and which interfaces are likely to create trouble later. If a critical component is still an off-the-shelf part with uncertain availability, that is not automatically a reason to stop. It is a reason to mark the dependency and decide when it must be resolved.

This is where you start hitting the long feedback loops that define climate hardware. Manufacturing iterations can take many months. Field testing often adds another long cycle on top of that. Regulatory approvals — depending on your sub-sector — can add further delay. The mistake founders make at the Alpha stage is assuming that because the bench works, the field will work. It won't, at least not automatically. The gap between those two realities is exactly what stages three and four are designed to close.

A working prototype in your lab is not the same thing as a buildable product. EVT is where the difference becomes obvious, and where most founders underestimate the cost of finding out.

Stage three: Engineering Validation Testing — your first production-quality build

Engineering Validation Testing is the stage most founders want to skip, and it's the one that quietly saves companies. EVT is the first time you build multiple units using production-quality tooling and manufacturing methods. Not benchtop parts. Not 3D-printed prototypes. Components that resemble what the manufacturing line will eventually produce, made through processes that can be measured, repeated, and improved.

The purpose of EVT is to validate that your engineering design can actually be manufactured at all. It answers questions such as:

• Does the injection mold produce parts within tolerance?
• Does the assembly process hold up when a person performs it repeatedly?
• Can the design be serviced without dismantling half the system?
• Are the electrical, mechanical, thermal, and software interfaces stable across more than one unit?
• Does the supply chain exist for the volumes you'll need later?
• Can incoming materials be inspected before they become expensive assembled failures?
• Can you identify the causes of variation, rather than simply sorting good units from bad ones?

These are not primarily scientific questions. They're operational questions, and they're the questions that determine whether you ship a product or ship a disaster.

EVT is also where documentation stops being optional. Drawings, bills of materials, assembly instructions, test procedures, calibration methods, and failure records become part of the product. If only the founding engineer knows how to assemble or troubleshoot the unit, the company has not yet built a manufacturing process. It has built a dependency on one person.

This stage typically corresponds to Manufacturing Readiness Levels 4 through 6, although the exact mapping depends on the product and the framework being used. If you're a non-technical founder, MRL is the language your contract manufacturer will speak, and it's worth learning before you walk into that first meeting. MRL 4 means you've validated the basic manufacturing concept. Higher levels require increasing evidence that the design, process, and supply base work together in a relevant setting.

Getting from one level to the next is not a ceremonial upgrade. It may require changing a material, redesigning a fastener, replacing a supplier, simplifying an assembly step, or accepting a small performance trade-off in exchange for reliability. That is why EVT should not be treated as a production rehearsal that the engineering team is expected to pass on the first attempt. It is a controlled effort to expose the weaknesses that a benchtop build hides.

For climate startups, the supply chain deserves particular attention. A component that is easy to order for ten prototypes may be difficult to source consistently for hundreds of units. A material that performs well in the lab may have a long lead time, limited manufacturing capacity, or quality variation between batches. If your product depends on a specialized cell, membrane, sensor, coating, power module, or industrial component, EVT is the time to find out what happens when the preferred supplier is late or the specification changes.

Stage four: Design Validation Testing — the product meets the world

If EVT is about whether the product can be built, Design Validation Testing is about whether the product deserves to exist in its intended environment. DVT prototypes should look and work like the final saleable product. They're fabricated using scale-oriented production processes — injection molding, casting, sheet metal work, or the relevant equivalent for the product — and they're tested against the conditions customers will actually create.

This is the stage where your thermal battery leaves the lab and sits in a utility substation through a real winter. Where your carbon capture unit runs on real flue gas from a real cement plant. Where your climate-sensing node spends a season in a real field, not a greenhouse. The variables you're testing now are not the ones you carefully controlled in Alpha. They're the ones you couldn't control: weather, dust, vibration, operator error, power quality, ambient temperature swings, contamination, network outages, maintenance habits, and a dozen other things that don't care about your data sheet.

DVT is not simply a longer demonstration. It is a test of the product's complete operating system: hardware, firmware, installation, instructions, service model, safety controls, and customer workflow. If a unit performs well but takes an hour of specialist attention every morning, that is a product problem. If operators bypass a warning because it triggers too often, that is a design problem. If the equipment requires a replacement part that the customer cannot stock, reliability is not the only issue; the deployment model is wrong.

DVT corresponds roughly to MRL 6 and 7, and it's where you discover whether your product survives contact with reality. Most climate hardware products reveal problems here, at least partially. That is not evidence that the team failed. It is evidence that the product has finally been tested in a way the lab could not reproduce.

The founders who survive are the ones who budgeted for iteration, not the ones who assumed DVT was a formality. Field testing cycles can extend across seasons, operating regimes, or customer budget cycles. Regulatory submissions may overlap with DVT in industries such as energy storage and industrial heat. When the field data forces you to change the design, you'll be grateful you didn't promise a customer a date you couldn't keep.

A strong DVT plan defines what counts as a successful test before the unit is installed. That includes performance thresholds, uptime expectations, acceptable maintenance intervals, safety events, data quality, and the conditions under which the test must be repeated. Without those definitions, teams tend to declare success when the equipment is still running and failure when a customer is angry. Neither is a useful engineering standard.

Stage five: Production Validation Testing — the pilot run

Production Validation Testing, or PVT, is the pilot production run. By this point, your product design is substantially mature, and changes should be controlled rather than improvised. What you're validating now is the manufacturing process itself: the supply chain, the assembly line, the quality-control procedures, the packaging, the logistics, and the handoff between the factory and the customer.

A PVT run is large enough to expose process problems that would not show up in EVT or DVT, but still small enough to manage before full production. The right size depends heavily on the product, the manufacturing method, and the amount of variation in the supply chain. The important point is not a universal percentage. It is whether the run is big enough to reveal the repeatability problems hidden by a handful of carefully supervised builds.

This is where the rubber meets the road for a different reason: you're now spending real money per unit. Every design tweak at PVT costs much more than a tweak at Alpha. Every supplier change takes time to propagate through procurement. Every assembly step that confuses the line worker becomes a defect rate you carry into full production. The PVT run is your last practical opportunity to find those problems before they multiply across the installed base.

PVT should be treated as a manufacturing experiment with commercial consequences. Track first-pass yield, rework, test failures, material substitutions, assembly time, and the reasons units are held back. A product that passes because the factory's most experienced technician personally fixes every unit is not ready for scale. Neither is a line that can meet the specification only when the incoming materials are hand-selected.

The customer handoff matters here as well. Packaging, installation instructions, spare parts, remote monitoring, and service escalation are not administrative details. They are part of the production system. A climate hardware startup often sells into environments where the customer cannot simply return a product and download a software update. The cost of a field correction includes travel, downtime, replacement equipment, lost trust, and the internal attention required to manage the incident.

Here's the field note that doesn't make it into accelerator pitch decks: many climate hardware companies need substantial time after an accelerator program ends to convert a working prototype into recurring revenue. That's not a commentary on accelerator quality. That's a commentary on how long hardware takes. If your financial model assumes revenue shortly after demo day, make sure it accounts for manufacturing validation, customer installation, field data, procurement, and the possibility that the first deployment changes the product.

The expensive shortcut: why skipping EVT and DVT costs more than it saves

I want to come back to the founder from the opening, because her decision illustrates the single most expensive mistake in climate hardware development. The pressure was real: a promising LOI, an impatient board, and a nine-month window. The temptation was to skip EVT and DVT and go straight from her Alpha prototype to a PVT-style pilot run.

She didn't. We mapped out what could happen if those stages were compressed. The risk was not abstract. If a pilot unit failed in the field, she could lose months finding a replacement design partner willing to take on a half-baked project. During that time, the utility's budget cycle could close, the original LOI could remain unsigned, and the competitor who took the slower path could become the safer procurement choice.

That distinction is important. The customer was interested, but the agreement was not final. Treating an LOI as if it were a purchase order had created false confidence inside the company. The team was planning against a commercial certainty it did not actually have.

The shortcut would not necessarily save nine months. It could simply move the validation work into the most expensive possible setting: a customer's site, under a public delivery promise, with limited access to the equipment and no room for a quiet redesign. A field failure does not prove that a particular recovery timeline will follow. It does prove that the company now has a technical, commercial, and relationship problem at the same time.

The broader pattern is familiar. Founders skip or compress a validation stage to chase a procurement deadline, then spend the next cycle rebuilding what they had skipped. Sometimes the failure appears in the first deployment. Sometimes it appears as poor yield at the factory, an unavailable component, an installation process nobody can execute, or performance that collapses outside the controlled conditions of the lab.

The trade-off is not speed versus rigor. It's deliberate learning now versus expensive uncertainty later.

A working framework for the next eighteen months

If you're standing up a climate hardware company right now, here's how I'd think about the budget and timeline across the five stages. The exact numbers vary by sub-sector — carbon capture looks nothing like battery storage — but the shape of the work is consistent.

The numbers above aren't gospel. They're a planning frame, not a promise. Some teams will run Alpha and early EVT work in overlapping loops. Others will discover during DVT that a core subsystem needs to return to engineering validation. A long-lead component can determine the schedule more than the nominal duration of any stage. So can access to a test site, a contract manufacturer, certification capacity, or a customer willing to host a difficult first deployment.

The five stages are best understood as a set of questions rather than a railway line:

1. POC / Pre-EP: Is the mechanism real enough to justify engineering effort?

2. Alpha: Can the team make the mechanism work intentionally and repeatedly in a controlled setup?

3. EVT: Can multiple units be built with a credible production path?

4. DVT: Does the integrated product perform safely and reliably in the environments where customers will use it?

5. PVT: Can the company reproduce that product through a real manufacturing and supply-chain process?

If a test at a later stage answers "no," the correct response is not to hide the result so the team can preserve the appearance of forward motion. Go back to the stage that owns the unanswered question. The calendar may look worse. The product will usually look better.

And if a contract manufacturer promises you a faster path, ask which work is being removed, deferred, or assumed away. A faster quote can be legitimate. It can also mean that the validation work is being pushed onto your engineering team, your customer, or the field.

The hard-earned lesson

The thing about climate hardware is that the science is rarely the only hard part. The science is what gets you into the accelerator, what gets you into the press, what gets you the term sheet. The difficult work continues afterward: manufacturing readiness, tooling decisions, supply-chain contracts, regulatory timelines, installation constraints, field validation, service procedures, and pilot runs. None of that fits neatly on a pitch slide, and all of it determines whether your company ships a product or ships a story.

The messy work is the work. Get comfortable with it before your seed round closes, not after.

The founders who make it treat the five-stage model as a discipline, not a sequence to optimize. They don't ask only, "How do we get through this faster?" They ask, "What do we need to learn at this stage that we cannot learn any other way?"

That reframe changes the conversation. It changes the budget. It changes the conversation with your board, your investors, and your early customers. It also makes iteration less embarrassing. Returning from DVT to Alpha is not automatically a setback if the test exposed a risk that would have been far more expensive to discover after production.

If you're early in the journey, build your financial model around long feedback loops. Plan for substantial iteration before you ship a paid pilot. Resist the pressure to compress validation simply because an LOI is on the table. An interested customer is valuable evidence, but it is not the same thing as a signed contract, a production forecast, or permission to skip engineering.

Not every company will label its work with exactly these five names. Some will combine stages; some will repeat them; some will run separate validation loops for different subsystems. But any climate hardware company that reaches real deployment has to answer the underlying questions: does the mechanism work, can it be engineered, can it be manufactured, does it survive the field, and can the process be repeated?

There is no reliable version of this that ships faster by pretending the questions do not exist. The five stages are not a rigid ladder. They are the work — including the loops back. Own them.