How to Launch a Hardware Product
"Launch" is the day your first manufactured unit reaches a paying customer. Everything before that has to be right. The commitments that must hold by launch day.
Search “how to launch a hardware product” and the first page is a Kickstarter playbook. Content in week one, press seeding in week four, pre-order countdown in week eight, campaign in week eleven. That framing treats launch as a marketing event. For a serious hardware product, it is not.
Launch is the day your first manufactured unit reaches a paying customer. That is the only definition that survives contact with reality. Everything before that day — the product, the factory, the firmware update path, the warranty reserve, the support workflow — has to be earned. The moment a customer pays, the business has made a commitment it cannot take back.
This page re-defines launch as commitments that must hold on day one, and works backwards. It is written for founders and CTOs shipping embedded systems, robotics, connected consumer hardware, and industrial equipment — not for teams running a crowdfunding campaign.
A hardware launch is not a marketing event. It is a load-bearing commitment. The day a paying customer receives unit one, you are on the hook for every unit you will ever ship of that SKU — firmware, warranty exposure, service path, spare parts, and the reputation of every unit that follows. Teams that ship before these commitments are earned do not get a second chance with the customers who bought first.
What “launching a hardware product” actually means
For software, launch is cheap. You ship, patch at 2am, and a bad first day costs a Hacker News thread. For hardware, launch is the point at which the program acquires a fleet. A unit in a customer’s hand cannot be recalled silently, cannot be hot-patched without a working update channel, and cannot be supported without a real human on a real phone.
Three things happen on launch day that do not happen before.
Unit cost becomes load-bearing. Every unit leaving the line has to have been built at or below the cost the business committed to. Not the cost at PVT — PVT is a hundred units and everyone is paying attention. The cost at unit ten thousand, with a line operator on a bad day, is what margin depends on.
The support path becomes contractual. The customer has paid. They have consumer protection statute behind them. If the product fails in week two, a path — replace, refund, RMA, field repair — has to exist, be staffed, and not require the firmware engineer who designed the board.
Every deferred decision becomes a liability. The serial scheme you did not finish. The calibration database on one engineer’s laptop. The firmware signing key not yet in an HSM. The spare parts forecast you never built. Operational debt that compounds with every unit shipped.
Launch is the transition from “building a product” to “operating a fleet.” Everything below works backwards from it.
The commitments that must hold on launch day
On the day the first paying customer receives a unit, a number of things have to be simultaneously true. Not “mostly true.” Not “true in the lab.” Not “true for the first hundred.” True, measured, and held across the population about to ship. These are the minimum viable operating model of a hardware business on day one.
Every row is something teams regularly ship without. They launch, then spend six months retrofitting the operating model under field pressure, with customers already holding units built before any of this was true. It is the most expensive way to build a hardware business.
The five preconditions teams systematically underestimate
The same five preconditions are underbuilt in most programs we see. They are not exotic. They are the unglamorous work between a product that passes PVT and a fleet that can be operated. See Why Hardware MVPs Fail for how this gap gets introduced in the first place.
Not a bench flashing script. A mechanism — OTA, USB, companion app, service tool — that moves a shipped unit from firmware N to N+1 without bricking it. Signed. Versioned. Rollback-capable. Tested on units off the real line, not hand-built bench boards. If it cannot recover from a failed update, it is not launch-ready.
Warranty accrual is not a guess. It is a per-unit cost derived from measured early-life failure data, projected over the warranty window. A two-year warranty, a one-percent annual failure rate, a hundred-euro replacement cost — that is a two-euro reserve per unit. It sits on the balance sheet and comes out of margin. Launching without it is launching blind.
First-line support is a person — internal or outsourced — following a written diagnostic flow, with access to calibration record, firmware version, and shipment batch for any serial. Escalation to engineering is a last resort. If every customer email lands in the firmware lead’s inbox, the program has not launched a product. It has launched a paid beta.
Every shipped unit carries a serial linked in a queryable database to its board rev, BOM rev, firmware version at ship, calibration data, and build date and line. When a failure emerges at unit 8,400, this is the only way to know whether it affects the first batch, the last, or one firmware window. Spreadsheets do not scale. Neither does the CM’s ERP without direct read access.
The production BOM is not the service BOM. Service needs connectors, seals, batteries, screens, silicone parts — stocked, kitted, held against a projected return rate. On a two-year warranty, service inventory covers at least that window. If the CM is your only source of spare silicone skirts and the mold is on their shelf, your spare parts plan is their next production run.
Each is a direct consequence of launch creating a fleet. The fleet imposes the load. The preconditions exist to carry it.
The marketing-launch trap
The standard internet answer to “how to launch a hardware product” is a marketing calendar, and it actively misdirects teams building serious hardware.
The trap has a predictable shape. A team picks a launch date — a trade show, a Kickstarter unlock, a press embargo — and works the marketing calendar backwards from it. Engineering is told the date is fixed. PVT gets compressed. The firmware update mechanism slides to “phase two.” Warranty modeling gets deferred. Units ship. Ninety days later, field failure rate is eight percent, support is drowning, the CM is doing unplanned rework, the founders are patching firmware by hand, and the company has spent its margin on RMAs for the quarter.
Marketing is not the problem. The trap is letting the marketing calendar set the engineering calendar. Different commitments, different failure modes, different clocks.
The cultural weight compounds it. A slipped marketing date looks bad. A quietly deferred firmware update mechanism is invisible — until three months later when it is a catastrophe. Treat engineering commitments as gating and let the marketing calendar follow.
How to build backwards from launch day
Start from the commitments and work out when each has to be real. Read right to left from launch day.
Launch day — unit one to a paying customer. Every commitment is true and has been true for at least two weeks. Units in distribution. Support staffed. RMA process rehearsed on internal failures.
L − 4 weeks — units in transit. First production run has landed. Quality inspection complete on a sample. Packaging, regulatory markings, and serial binding verified. Support trained on the actual product. Firmware update path exercised end-to-end on a production unit.
L − 8 weeks — first production run underway. CM building the first volume batch. End-of-line test at line speed. Yield data coming in. Calibration database populated as units come off the line. Certification reports final. Warranty reserve approved by finance, per-unit accrual derived from DVT/PVT failure data.
L − 16 weeks — PVT complete, tooling cut. PVT has produced a yield number the business can commit to. DFM issues closed. Service BOM ordered. CM booked. Support workflows exercised on PVT units. See From Prototype to Production for the decision framework governing the program to this point.
L − 30 weeks — DVT complete, BOM locked. Environmental, regulatory, reliability testing passed. Certifications submitted. Second sources qualified. Firmware frozen for DVT; update mechanism designed and prototyped. CM contract signed. See Choosing a Contract Manufacturer (From the Inside) for how this commitment is negotiated.
L − 52 weeks — EVT complete, architecture frozen. Product works in hardware. Architecture justified against production. The fleet-grade decisions — update path, serialization scheme, calibration strategy, service BOM philosophy — designed in, not retrofitted.
This is the calendar of a program that does not melt down ninety days after launch.
What a launch-ready program actually looks like
A program that ships cleanly does a few things differently.
It treats launch day as a gate, not a celebration. Internal language is “we are ready to accept the fleet obligation” — not “we are ready to announce.” Every checklist item has an owner and evidence: a signed test report, a measured yield number, a demonstrated update path on a production unit, a signed warranty accrual from finance.
It ships a small first wave deliberately. Not the full pre-order queue. Five hundred units, a thousand — going to a segment pre-qualified as tolerant of early-life iteration. The fleet learns the field in a population where feedback is actionable and a surprise is not a retail return.
It has a staged firmware rollout. First push goes to five percent of the fleet. Telemetry is watched. The next push is gated on the previous one not regressing. Standard practice in software, almost never standard in hardware, and the single most effective way to prevent a bad firmware from bricking a field.
It has a weekly ops review chaired by someone who owns the fleet. Not marketing. Not engineering. An operator who watches yield, failure rate, RMA volume, support load, spare parts burn, and CM quality escapes, and trades off across them. This role is where most first-time hardware companies are structurally thin — which is why teams bring in an ad-hoc CTO for the launch window.
It has the second run already planned. Production is a cadence, not a run. The second PO is on the CM’s schedule before the first run ships. Teams that treat the first run as a one-off spend four months re-qualifying every decision they thought was locked.
Our framework is structured to deliver exactly this shape of program: phases that converge on launch-day commitments, not on a marketing date.
When to pull launch — and when to push through
The hardest decision in a hardware launch comes six weeks out, when the first production run is landing and something is not quite right. Yield is below PVT. The firmware update mechanism failed on two units out of a hundred. The certification report has a conditional. Ship the date, or pull it?
There is no general answer. There is a test. Pull if any of four conditions holds.
Firmware update path is not robust. If you cannot patch a deployed unit with high confidence, any firmware defect becomes a physical recall. Everything else can be worked around. This cannot.
Yield problem is not characterized. If yield is below expectation and nobody knows why, shipping does not produce data. It produces a larger population of the unknown failure. Pull until the CM has a corrective action that explains the variance.
Certification is not in hand. Not “submitted.” Not “expected next week.” In hand. Shipping a non-certified unit into a regulated market is known-to-be-illegal.
Support path does not exist. If no staffed human can triage an RMA, there is no launch. Shipping without support is shipping a complaint queue.
Push through if the issue is cosmetic, isolated to a non-safety-critical feature, has a corrective action for the next run, and does not touch any of the four above. Packaging color mismatch — push through. Aesthetic LED misalignment — push through. Ten-percent-under-spec battery life recoverable by a month-two firmware update — maybe, if the customer communication is clean and the update actually lands.
A pulled launch loses weeks. A bad launch loses a year. The asymmetry favors the pull if any of the four hard conditions is open.
Delay before launch is cheap. Delay after launch is expensive. A program that pulls to fix a firmware update mechanism buys six weeks. A program that launches with a broken update mechanism buys a year of field failures, an exhausted support team, and a reputation that does not recover. The asymmetry is not subtle.
The next step if you are six months out
If you are six months from what you think is launch, the question is not “are we going to make it.” It is “are the commitments in the readiness matrix tracking to converge by launch day.” In most programs we are brought into at this stage, some are and some are not — and the ones that are not are always in areas the team lacks deep in-house experience: firmware update infrastructure, warranty modeling, support workflow.
This is where external senior leadership is most economical. Not because the in-house team is not capable — usually it is. Because the production-to-launch transition is a pattern-recognition problem most teams run once or twice in a career, and the failure modes are paid in months of lost market position, not euros.
A good external lead in this window forces three things. The launch definition gets written down — the commitments matrix filled in with real names and real evidence per cell, not a marketing date. The tradeoffs get named — pull the date, drop the feature, accept the risk with a named mitigation. The CM relationship gets operated at launch scale — an external lead who has run production ramps knows which conversations the CM expects, which escalations they respond to, and which silence is a problem being hidden.
Rheo Dive, our consumer dive mask program, ran this end to end — POC, EVT, DVT, PVT, mass production. A product that operates under twenty meters of saltwater, running decompression calculations the customer’s life depends on. Every commitment was earned before the first paying customer received a unit. Not because the team was lucky. Because launch was defined as the commitments, and the date followed.
Teams that ship clean hardware launches do not do it by moving faster. They move in the right order. Backwards from the fleet obligation. Never forwards from the press calendar.
Six months from launch and not sure every commitment is tracking to converge?
We work as ad-hoc CTO and senior product team through exactly this window — translating a PVT-ready product into a fleet-ready operating model, before the first paying customer receives a unit. Every engagement starts with a fixed-scope definition phase. No open-ended billing. No ambiguous timelines.
Start a Conversation