Lab prototype to production: scaling climate hardware

A utility partner wants a pilot date. A commercial customer has signed a Letter of Intent. Investors are asking when the company will begin generating revenue. The lab team says the system is ready for “real-world testing,” while the manufacturing partner is already asking questions about tolerances, component availability, certification, service access, and repeatability.

The temptation is obvious: move straight from a successful lab prototype to a small commercial run.

That is also where many climate hardware companies create their most expensive problems.

A functioning lab prototype is not a production-ready product. It may demonstrate that the underlying science works, but it usually covers only about 30% of the work required to reach a manufacturable, certifiable, reliable product. The remaining work is less glamorous: engineering validation, design for manufacturing, supply-chain decisions, field reliability, documentation, test fixtures, quality controls, and the uncomfortable discovery of which parts of the design were never robust outside the lab.

The climate hardware prototype to production transition is not one large leap. It is a sequence of increasingly unforgiving tests. Skipping one of those steps can save time on a planning document and destroy an entire seed runway in the field.

The 30% reality: a working prototype is an early answer

A lab prototype answers a narrow question:

Can this technical concept perform under controlled conditions?

Production asks a much broader set of questions:

• Can the product be built repeatedly rather than once?
• Can another technician assemble it without the original researcher standing nearby?
• Will it perform when temperature, humidity, vibration, contamination, or operator behavior changes?
• Are the parts available in the required quantity?
• Can the design be inspected and repaired?
• Does the product meet applicable certification and safety requirements?
• Can the company explain what went wrong when a unit fails?
• Is the product economical to manufacture, install, operate, and service?

Those are different questions, and they arrive at different moments.

In a lab, a founder can tolerate hand-tuned components, manual calibration, improvised fixtures, and a small number of highly capable people who know every quirk of the system. Production cannot depend on institutional memory. A product that works only when a particular engineer adjusts a valve, rewires a sensor, or interprets an unusual signal is not yet a product. It is a demonstration with expert support.

This is the first trade-off founders need to make explicit: technical proof is not the same as operational readiness.

The distinction matters especially in climate tech because the product often operates in difficult environments and interacts with existing infrastructure. A carbon capture module, thermal storage system, industrial sensor, grid asset, or water-treatment device may be installed outdoors, in a plant, on a construction site, or in a location where service visits are expensive. Small design weaknesses become large operating costs when the customer is not a laboratory.

A lab prototype proves that the idea can work. Production engineering proves that the company can make it work again, somewhere else, for someone else.

The gap also changes the economics. A lab prototype may be assembled from off-the-shelf components, custom-machined parts, temporary wiring, and equipment already available to the team. A production version needs a defined bill of materials, controlled specifications, suppliers, assembly processes, quality checks, and a plan for substitutions when a component becomes unavailable.

That is why the phrase “we only need to manufacture a few units” can be misleading. A small pilot does not remove the need for production discipline. It often exposes it earlier.

Five stages between concept and commercial production

Climate hardware prototyping typically moves through five stages: Proof-of-Concept, Alpha or Engineering Prototype, Engineering Validation Testing, Design Validation Testing, and Production Validation Testing.

The names can vary across companies and industries. The underlying progression is more consistent: first prove the principle, then prove the engineering, then prove the design, and finally prove that the production process can deliver the design repeatedly.

1. Proof-of-Concept: does the mechanism work?

The Proof-of-Concept stage is where the company demonstrates the central technical claim.

The system may be small, manually operated, or built around components that would never appear in a commercial unit. That is acceptable. The POC is not supposed to settle every manufacturing question. Its job is to establish that the proposed mechanism, chemistry, control approach, or energy conversion pathway is worth developing further.

A useful POC should make its boundaries visible. Record the conditions under which it worked, the operator interventions it required, and the assumptions embedded in the setup. If the performance depends on a narrow temperature range or a specific feedstock quality, write that down now. These constraints will become design inputs later.

The mistake is not having a rough prototype. The mistake is treating the rough prototype as evidence that the commercial architecture is already known.

2. Alpha: turn the science into an engineered system

The Alpha or Engineering Prototype stage starts converting a technical demonstration into a system with defined subsystems and interfaces.

This is where the team begins making decisions about:

• Component selection and expected operating range
• Mechanical and electrical interfaces
• Sensors and control logic
• Enclosures, thermal management, and access panels
• Safety mechanisms and failure responses
• Installation and maintenance requirements
• Data logging and remote monitoring
• Early manufacturing constraints

An Alpha unit may still be expensive, imperfect, and difficult to assemble. That is not a failure. It is a working engineering object that allows the team to find the failures that the POC was never designed to reveal.

For a non-technical climate founder, this is often the point where the company needs more than a technical advisor. It needs someone who can own the product development lifecycle: requirements, architecture, test plans, supplier conversations, change control, and decisions about what the next build must prove.

A technical cofounder is one route. A fractional head of hardware, systems engineer, or experienced product development lead may be another. The key is not the title. It is clear ownership of engineering trade-offs before customer commitments turn every unresolved question into an emergency.

3. EVT: does the engineering work under defined conditions?

Engineering Validation Testing, or EVT, tests whether the engineering design performs against explicit requirements.

The phrase “it works” is too vague for EVT. The team needs to define what success means:

• What output or efficiency range must the unit achieve?
• Under which operating conditions?
• For how long?
• With what allowable variation?
• What happens when a sensor fails?
• What is the acceptable startup and shutdown behavior?
• Which safety events must trigger an automatic response?

EVT is not merely a longer pilot. It is a structured attempt to validate the engineering choices.

The test plan should connect each requirement to a measurement and an acceptance threshold. If the product is intended for a utility or industrial customer, the test plan should also reflect the actual operating environment rather than only the conditions that are convenient in the lab.

This is where teams often discover that a system-level metric hides a subsystem problem. The overall output may look acceptable while a pump is operating outside its preferred range, a thermal interface is degrading, or a control loop is masking instability. EVT gives the team a chance to find those issues before the customer becomes the test environment.

4. DVT: does the product design hold together?

Design Validation Testing, or DVT, evaluates the product as designed for its intended use.

The question changes from “does this engineering configuration perform?” to “does the product design meet the user, environmental, regulatory, and reliability requirements we have committed to?”

DVT should bring in the realities of deployment:

• Installation by people who did not design the system
• Normal variation in materials, site conditions, and operator behavior
• Enclosure and environmental protection
• Noise, vibration, heat, moisture, and contamination
• Service access and replacement procedures
• User interface and alarm handling
• Certification and compliance requirements
• Packaging, shipping, and site acceptance

A climate product can fail commercially without failing scientifically. It may meet its performance target but require too much specialist labor to install. It may produce the right output but be impossible to service without shutting down an entire site. It may operate safely in principle but lack the documentation required by a customer’s procurement or safety team.

DVT is where these issues become product requirements instead of anecdotes.

Design for manufacturing climate tech also becomes concrete here. DFM is not a final review performed after the “real” design is complete. It is the practice of removing unnecessary complexity, reducing assembly variation, selecting realistic materials and processes, and making the product easier to inspect and repair.

A design that is elegant in CAD but difficult to fabricate, align, seal, wire, or test is not elegant for the business. It is carrying hidden labor into every unit.

5. PVT: can the production process make the product?

Production Validation Testing, or PVT, is the final validation stage before commercial runs. It tests not just the product but the process used to build it.

The same design can produce different outcomes depending on who assembles it, which supplier provides a part, how torque is controlled, how calibration is performed, and whether a quality check catches a defect before shipment.

PVT should therefore examine:

• Repeatability across multiple units
• Assembly instructions and work instructions
• Supplier consistency
• Incoming inspection
• Calibration and end-of-line testing
• Traceability of components and changes
• Defect handling and rework
• Packaging and shipping
• Production yield and the causes of failure

The exact path from DVT to PVT depends heavily on tooling, supplier readiness, product complexity, and regulatory certification. There is no universal timeline that a founder can safely copy from another hardware category.

What can be copied is the discipline of asking whether the next batch is being used to learn about the product, the process, or both. If every unit is still assembled as a custom project, the company is not yet validating production. It is continuing development under a customer deadline.

A practical stage-gate system for founders

The five stages become useful when each one has a decision attached to it. Without a gate, “EVT” and “DVT” can become labels added to a slide deck after the fact.

A simple internal review can ask four questions at the end of each stage:

1. What did we intend to prove?

State the technical, operational, or customer requirement in plain language.

2. What did the evidence actually show?

Separate measured results from assumptions, estimates, and operator observations.

3. What remains unresolved?

Name the open risks instead of burying them in a general statement that the product is “progressing.”

4. What must be true before the next build?

Turn lessons into design changes, test requirements, supplier actions, or customer expectation-setting.

The documentation does not need to be bureaucratic. It does need to be honest. A short test report with clear failures is more valuable than a polished progress memo that leaves the next team to rediscover the same problem.

This table is deliberately less comforting than a simple “prototype to production” funnel. Each stage closes a different category of uncertainty. Passing one stage does not grant permission to assume the next one is solved.

Capital intensity: the equity premium is part of the strategy

Climate hardware startups typically require 20% to 50% more equity capital than software startups. When physical production facilities and infrastructure are included, total capital needs can approach twice those of a comparable software venture.

That difference is not just a matter of buying equipment. Hardware consumes capital before revenue becomes predictable:

• Engineering builds happen before the product can be sold repeatedly.
• Tooling and fixtures may be required before volume justifies them.
• Components may need to be purchased ahead of customer payment.
• Certification and compliance work can precede deployment.
• Field failures create replacement, travel, and support costs.
• Manufacturing partners may require minimum order quantities.
• Working capital becomes tied up in inventory and work in progress.

This is the financial version of the prototype gap. A software team can often change the product through code and redeploy it. A hardware company changes a part, a tool, a supplier, or a production process. The change may take weeks or months to appear in a new unit, and the old inventory may already be committed.

The right question is not simply, “How much money gets us to the pilot?” It is:

Which validation stage will this financing actually complete, and what evidence will exist at the next fundraising point?

That framing creates a more useful capital plan. Instead of raising a round around a vague production ambition, map funding to risk reduction:

• Early capital supports POC and Alpha work.
• The next financing should fund engineering validation, design iteration, and the systems required to test properly.
• Later capital may cover DVT, certification, tooling, production setup, inventory, and pilot deployment.
• Commercial scale requires a separate conversation about manufacturing capacity, working capital, and operational financing.

The boundaries will differ by business. A low-complexity sensor product does not have the same capital profile as industrial thermal equipment. But the principle holds: funding should match the physical and regulatory work still ahead, not the emotional milestone the team wants to announce.

A founder who underfunds validation does not eliminate the cost. The cost reappears as rushed redesigns, delayed deployments, unusable inventory, emergency supplier changes, and damaged trust with the first serious customer.

The “valley of death” is not only a funding gap. It is the period when the company must pay for production-grade evidence before the market is willing to pay for production-grade hardware.

Why a Letter of Intent cannot carry a manufacturing plan

Letters of Intent are useful. They can show that a customer has a problem, that the proposed solution is relevant, and that a deployment conversation has enough substance to continue.

But an LOI is not a binding purchase contract. It does not guarantee revenue, delivery acceptance, payment timing, site readiness, or tolerance for early product failures.

That distinction becomes dangerous when founders use an LOI to justify skipping EVT or DVT. The logic usually sounds reasonable:

• The customer needs the product now.
• The pilot is small.
• The customer understands that the technology is early.
• The LOI proves demand.
• More testing can happen after installation.

The problem is that the field is not a neutral extension of the lab. It introduces new dependencies: site conditions, safety reviews, installation crews, network access, maintenance procedures, procurement rules, and the customer’s own operational priorities. A failure in the field can cost more than the hardware. It can consume the design partnership that was supposed to produce the next round of evidence.

A better approach is to turn the LOI into a learning agreement with explicit boundaries. Before committing to a pilot, clarify:

• What the pilot is intended to demonstrate
• Which performance metrics will be measured
• Which conditions are required at the site
• Who owns installation and commissioning
• What happens if the unit underperforms
• What support the startup must provide
• Which failures are acceptable for a development pilot
• What would trigger a redesign before the next deployment
• Whether the customer has made a purchase commitment or only expressed interest

This is not about weakening the relationship with the customer. It is about replacing mutual optimism with shared operating assumptions.

For founders, the emotional challenge is real. A customer deadline feels like validation, and pushing back can feel like losing momentum. But a partner who expects a production-ready asset may interpret a preventable failure as incompetence, even if the company described the product as early-stage.

The most credible sentence in that conversation may be: “We can meet this date with a development unit, or we can move the date and deliver a validated design. Those are different commitments.”

Strategic sequencing: protect the pilot without pretending it is production

There is a false choice between moving quickly and engineering carefully. The real choice is whether speed is being applied to learning or to shipping uncertainty.

A climate hardware company can often maintain momentum without skipping validation by separating the pilot plan from the commercial production plan.

Use the pilot as a bounded experiment

A development pilot should have a defined purpose. It may be designed to test performance in a specific environment, validate an installation workflow, collect operating data, or understand how the customer’s existing system interacts with the new product.

Do not promise every future product capability in the first deployment. Choose the questions that matter most for the next financing and the next design revision.

Keep pilot units visibly different from commercial units

If the unit is still an engineering build, treat it as one operationally. That can mean additional monitoring, planned access for technicians, conservative operating limits, and a written maintenance arrangement.

The customer should understand what the unit is and is not. The company should know which features are temporary and which are intended to carry forward. Otherwise, a prototype gradually becomes a permanent product through sheer calendar pressure.

Build manufacturing knowledge before volume

Talk to manufacturing and supply-chain specialists earlier than feels necessary. The goal is not to outsource the problem. It is to learn which design choices create downstream cost and delay.

For each major subsystem, ask:

• Is the part available from more than one supplier?
• Are the specifications clear enough for a second supplier to reproduce?
• What is the inspection method?
• Which components have long lead times?
• Which parts require custom tooling?
• What happens if the preferred component is discontinued?
• Can the assembly be performed consistently?
• Can a field technician replace the part without specialist equipment?

These questions may lead to a design pivot. That is not wasted work. A pivot before tooling and inventory commitments is usually less painful than a pivot after the commercial pilot has failed.

Separate technical readiness from commercial readiness

A product can be technically promising and commercially unready. It can also be commercially interesting while still technically immature.

Track both dimensions. Technical readiness includes performance, reliability, safety, and repeatability. Commercial readiness includes customer workflow, installation, service, procurement, pricing logic, and support capacity.

Neither side can substitute for the other. Strong test data will not solve an impossible installation model. A motivated customer will not compensate for an unstable product.

Fund the uncomfortable middle

The most vulnerable part of the hardware startup manufacturing transition is often the stretch after the lab result and before repeatable production. It is expensive because the company must build evidence, not just features.

When planning the next round, include the unglamorous work:

• Test equipment and fixtures
• Engineering support
• Supplier qualification
• Design revisions
• Certification preparation
• Manufacturing documentation
• Pilot logistics
• Field service and failure analysis
• Inventory and replacement units

If the budget only covers the units promised to the customer, it probably does not cover the transition.

The operating habits that make scaling less fragile

The best hardware teams are not necessarily the teams with no failures. They are the teams that make failures legible early enough to act on them.

A few habits have disproportionate value:

1. Maintain a live risk register.

Track technical, supply-chain, regulatory, installation, and customer risks together. A component shortage can become a product redesign; a certification question can become a schedule problem.

2. Record configuration changes.

Know which version of the design was tested, which components were used, and what changed between units. Without configuration control, performance data becomes difficult to interpret.

3. Test the handoffs.

Ask whether a supplier, assembler, installer, or service technician can complete their part of the process without informal knowledge from the founding team.

4. Measure the cost of failure, not only the cost of parts.

A low-cost component that causes a site visit, a delayed installation, or a customer shutdown is not low-cost in operation.

5. Give every pilot a post-mortem.

Review what failed, what was merely inconvenient, what surprised the team, and which assumptions should be removed from the next plan. Do this while the evidence is still fresh.

6. Treat resilience as an engineering requirement.

Climate products operate in systems exposed to weather, infrastructure constraints, policy changes, and uneven maintenance capacity. Resilience is not a brand attribute added later. It is part of product performance.

These practices can feel slow when the company is under pressure. In reality, they create optionality. A team that understands its failure modes can decide where to simplify, where to spend, and where to say no. A team that does not understand them is forced into reactive decisions by the next missed delivery or broken unit.

The hard-earned lesson

The climate hardware prototype to production transition is not won by declaring that the prototype is “almost ready.” It is won by making the remaining work visible and financing it honestly.

The five stages—POC, Alpha, EVT, DVT, and PVT—are not ceremony. They are a way to keep different kinds of uncertainty from hiding inside the same optimistic sentence. EVT protects the company from shipping an engineering problem. DVT protects the customer from receiving a product that works only under friendly conditions. PVT protects the business from discovering, too late, that every unit is effectively handmade.

There will still be messy trade-offs. You may need to narrow the pilot, delay a feature, redesign around an available component, or raise more equity than a software founder would expect for a similar commercial milestone. Those choices are frustrating. They are also part of building a durable climate business rather than an impressive demonstration.

The practical lesson is simple: do not use customer urgency as evidence of manufacturing readiness.

Use it as a reason to sequence the work better, define what the next unit must prove, and protect enough runway to reach production without pretending the valley between the lab and the market is smaller than it is.