What I Wish I Knew Before Launching Hardware
Hardware has a way of turning small assumptions into large invoices.
A software bug can be patched after launch. A bad enclosure tool, a weak hinge, a battery that fails testing, or a supplier that quietly changes material can stop a company in its tracks. That does not mean hardware is too risky. It means the work asks for a different kind of patience.
After helping dozens of founders bring physical products to market, I have seen the same lessons repeat. The strongest teams are not always the ones with the best idea or the most polished prototype. They are the ones that learn early, ask plain questions, and treat every part of the product as part of the business.
Here is what I wish more founders knew before launching hardware.
A prototype is not proof that the product is ready
The first prototype feels like a breakthrough, and it should. Holding the thing in your hand changes the project. It makes the idea real.
But a prototype answers only a narrow set of questions.
It can show that the mechanism works, that the interaction feels right, or that the size is reasonable. It does not prove that the product can be built repeatedly, shipped safely, passed through compliance testing, or serviced when something goes wrong.
A prototype is usually built with extra care, extra time, and extra tolerance for flaws. Production is different. Production asks whether a product can survive ordinary mistakes at scale.
Before treating a prototype as validation, ask:
Can the same build be repeated 100 times with the same result?
Which parts are custom, and which are available from more than one supplier?
What breaks first under daily use?
What happens if a user drops it, stores it in heat, or plugs it in wrong?
Can it be assembled by someone who did not design it?
That last question is painful and useful. If only the founding team can put the product together, the design still depends on founder heroics. That will not hold.
The shift is simple: use prototypes to reduce risk, not to create confidence theater.
The customer problem needs to be sharper than the product idea
Many hardware founders start with the object. A better camera mount. A connected kitchen tool. A wearable device. A portable charger. A smart sensor.
The object matters, but the problem matters more.
A physical product asks customers to change their space, habits, and sometimes their budget. It has to earn that place. If the problem is soft, the product becomes a novelty. People may like it. They may praise it. They may even sign up for updates. Then launch day comes, and they do not buy.
Watch for weak signals that feel stronger than they are:
Friends say they would use it.
Survey respondents say the concept is interesting.
People like the design render.
Early testers enjoy playing with the prototype.
Retail buyers say to come back when there is traction.
Better signals usually involve effort or tradeoff. Someone pays a deposit. Someone replaces an existing solution. Someone uses an ugly prototype because the benefit is strong enough. Someone asks when they can get two more.
The best early research is not fancy. Sit near the problem. Watch people do the work they already do. Ask what they tried before. Ask what they hate about current options. Ask what they would stop using if your product worked.
A founder who understands the before state can make better product decisions than a founder who only imagines the after state.
Unit economics need to show up earlier than feels natural
Cost can feel like a finance task, something to clean up after engineering and design settle down. That is a trap.
In hardware, cost is a design constraint from the start. Every material choice, fastener, sensor, process, package insert, and return policy touches margin. By the time a product looks finished, many cost decisions are already locked in.
A basic model should include more than the bill of materials. The bill of materials is only one slice of the true cost.
Cost area | Why it matters |
Parts and materials | Small part changes can affect price, availability, and assembly time. |
Labor and assembly | A design with fewer operations is often more valuable than a cheaper part. |
Tooling and fixtures | Upfront costs can be high, and changes after tooling can hurt. |
Testing and quality checks | Skipping checks often moves the cost to returns and repairs. |
Packaging and freight | Size and weight can reshape the business model. |
Duties, warehousing, and returns | The landed cost is what matters, not just the factory quote. |
The goal is not to predict everything perfectly. The goal is to see which assumptions carry the most risk.
If the product only works as a business when every quote is perfect, the price is premium, returns are low, freight is cheap, and manufacturing runs smoothly, the plan is fragile.
Strong hardware teams build margin for reality.
Manufacturing should influence the design before the design feels done
A common mistake is treating manufacturing as the next chapter after product design. In practice, manufacturing feedback should shape the product while changes are still cheap.
Good manufacturing partners can point out issues that are hard to see in CAD:
A part that will be hard to mold cleanly
A snap fit that may weaken after repeated use
A finish that will show scratches too easily
A tolerance stack that creates inconsistent assembly
A cable routing choice that slows down the line
A part that depends on a supplier with long lead times
Bring manufacturing input in early, but keep your judgment. A factory may suggest changes that make production easier while hurting the customer experience. The founder’s job is to balance both.
The best conversations with suppliers are specific. Instead of asking, “Can you make this?” ask:
What part of this design will create the most scrap?
Which tolerance is hardest to hold?
Where would assembly slow down?
Which part would you redesign if this were your product?
What would you change before tooling?
A good supplier will not be offended by clear questions. Clear questions make the project easier to quote and easier to build.
The schedule will be wrong unless it includes waiting
Most hardware timelines are too neat. They include design, prototyping, tooling, pilot run, production, and launch. They leave out the waiting.
Waiting for samples. Waiting for test results. Waiting for parts. Waiting for a supplier to come back from a holiday. Waiting for a fixture to be rebuilt. Waiting for a compliance issue to be explained. Waiting for freight to move.
This waiting is not laziness or bad luck. It is part of the system.
A more honest schedule includes loops. Design changes after testing. Tooling changes after first shots. Packaging changes after drop testing. Firmware updates after hardware revisions. Assembly instructions change after operators find a better sequence.
If the plan has no loops, it is not a plan. It is a wish.
For launching hardware, I would rather see a schedule with visible risk than a polished timeline that assumes everything works the first time. Investors, retailers, and customers may not love hearing that a date has buffers. They dislike missed promises more.
Build the launch plan around what must be true, not around the date everyone wants.
Quality is a system, not a final inspection
Founders often imagine quality control as someone checking finished units at the end of the line. That check matters, but it is too late to carry the whole burden.
Quality starts in design. It continues through supplier choice, incoming inspection, assembly fixtures, test procedures, packaging, documentation, and customer support.
A product with 30 steps and unclear pass or fail criteria will create confusion. A product with fewer steps, clear fixtures, and simple test results gives the team a better chance.
Good quality questions sound boring, which is exactly why they work:
What does a pass look like?
What does a fail look like?
Who decides?
Where is the result recorded?
What happens to failed units?
How do we know if a defect is repeating?
Which defects are safety issues?
Which defects are cosmetic but still unacceptable?
A founder does not need to become a quality engineer. But the founder does need to care before customers become the inspection team.
Returns are not just lost revenue. They are clues. Early returns can reveal design flaws, unclear instructions, weak packaging, or mismatched customer expectations. Treat them as product data, not only support tickets.
Packaging is part of the product
Packaging is easy to underestimate because it looks like the end. For customers, it is the beginning.
Packaging has to protect the product, explain the first steps, fit the channel, manage cost, and create confidence without waste. It may also need warning labels, compliance marks, barcodes, inserts, or retail requirements.
Bad packaging creates expensive problems:
Products arrive damaged.
Customers miss critical setup steps.
Warehousing costs rise because boxes are too large.
Retail partners reject shipments for labeling issues.
Replacement parts and returns become harder to process.
Packaging should be tested with the same seriousness as the product. Ship samples across the country. Drop them. Leave them in a hot vehicle. Hand them to someone who has never seen the product and watch what they do without coaching.
If someone opens the box and immediately asks, “What do I do next?” the packaging has work to do.
Preorders can help, but they also create pressure
Preorders are tempting. They can prove demand, fund production, and create urgency. They can also trap a company inside promises made too early.
The danger is not only missing a ship date. The bigger danger is locking in price, features, materials, colors, or delivery terms before the team understands the true cost and risk.
A preorder campaign should be built with restraint. Promise less than you hope to deliver. Explain what is final and what is still changing. Keep backers informed without turning every update into a performance.
A clear preorder plan includes:
A realistic production status
Known risks written in plain language
A refund policy
Conservative delivery estimates
A support plan for questions
A cash plan that does not spend every dollar before production is stable
Trust is a real asset in hardware. Once lost, it is hard to rebuild.
The founder’s job changes during production
Early in the project, founders often do everything. They sketch, sell, test, assemble, pack, answer emails, and chase suppliers. That intensity is normal.
During production, the job has to change.
The founder must move from making every decision by instinct to building a system other people can follow. That means clearer documentation, better handoffs, written acceptance criteria, and fewer mystery decisions trapped in one person’s head.
This can feel slow. It can feel less creative. It is also how the company grows past the first heroic batch.
Helpful documents do not have to be huge. They need to be used.
Create simple versions of:
Assembly instructions with photos
Approved supplier lists
Part revision records
Quality check sheets
Packaging instructions
Known issue logs
Customer support scripts
Return reason categories
The goal is not paperwork for its own sake. The goal is repeatability.
If the product gets better only when the founder is standing next to it, the system is not ready.
The launch is not the finish line
A hardware launch can feel like the peak. The site goes live, orders come in, boxes ship, and the team finally sees the product in the world.
Then the real feedback starts.
Customers use products in ways teams did not expect. They skip instructions. They use the device in different environments. They notice noises, fit issues, delays, confusing lights, weak magnets, rough edges, loose lids, fragile clips, and unclear app states.
This is not failure. This is the first honest operating environment.
Plan for the post-launch phase before launch day. Keep spare units and spare parts. Track issues by batch. Separate one-off complaints from patterns. Make it easy for customers to send clear information. Decide which problems need refunds, replacements, repair guides, software updates, or design changes in the next production run.
The best hardware companies do not treat version one as a monument. They treat it as a working product that can teach them.
What I would do differently now
If I were starting a hardware company from zero, I would move slower at the moments that look fast and faster at the moments that look abstract.
I would spend more time watching the customer problem before designing the object. I would build ugly prototypes sooner, but I would be slower to call any prototype finished. I would talk to manufacturers before the design felt ready. I would model costs earlier and update them often. I would test packaging before it looked beautiful. I would build quality checks into the process instead of hoping inspection catches everything later.
Most of all, I would respect the physical world.
Hardware rewards teams that are honest about constraints. Gravity, heat, friction, tolerances, batteries, freight, lead times, and human behavior all get a vote. Ignoring them does not make the product more ambitious. It makes the company easier to break.
The good news is that every one of these lessons can be learned before the most expensive mistakes happen. Ask better questions early. Build smaller proof points. Write things down. Test the boring parts. Leave room in the plan for reality.
A physical product is hard because it has to work in the world. That is also what makes it worth building.
Comments