At Supernova, we say we help companies make better products at scale.
“Better" means many things to us.
A product people actually want.
A product that is better engineered.
A product with a stronger cost structure.
A product that is easier to industrialize.
A product that can scale without falling apart.
But one meaning is non-negotiable:
Better quality.
And in hardware, quality is rarely where founders think it is.
Most founders think quality happens at the end.
At the factory. During QC. When someone checks finished units before shipment and decides whether they pass or fail.
That is the visible part of quality.
It is also the part that usually comes too late.
By the time a product reaches final inspection, most quality problems are already inside the product. The factory is not creating them from nowhere. It is revealing decisions that were made weeks or months earlier.
A vague requirement. A risky architecture. A fragile component choice. A missing test point. A tolerance nobody challenged. A certification requirement discovered after the enclosure was already tooled.
That is why quality is so often misunderstood in hardware.
Quality is not something you inspect into a product at the end.
Quality is something you engineer, industrialize, validate and control throughout the NPI process.
QC can catch defects. It cannot redesign your architecture, fix your BOM, simplify your assembly, recover your certification strategy or turn a proof-of-concept into a scalable product.
You cannot inspect your way out of bad engineering.
And you definitely cannot QC your way out of a weak NPI process.
In hardware product development, quality often gets created in moments where nobody is talking about quality.
It starts when the product requirements are written. It continues when the architecture is chosen, when the BOM starts taking shape, when target cost is defined, when certification constraints are understood, when suppliers are selected, when DFM starts, when validation is planned and when the production test strategy is designed.
Those are the real quality moments.
Each decision either protects the product or creates future risk.
A vague requirement becomes a wrong assumption. A wrong assumption becomes a weak design choice. A weak design choice becomes an assembly issue. An assembly issue becomes a yield problem. A yield problem becomes a customer complaint.
That is how quality usually fails.
Not dramatically.
Quietly. Early. One reasonable compromise at a time.
The dangerous thing about quality problems is that they rarely look obvious at the beginning.
A slightly cheaper component. A connector that is “good enough” for the prototype. A missing tolerance analysis. A vague cosmetic standard. A supplier nobody really qualified. A test that gets pushed to later.
Each decision seems manageable in isolation.
But hardware does not fail in isolation.
Everything stacks.
One weak decision adds stress somewhere else. Then another one. Then another one.
By the time the product reaches pilot production, the issue looks like a factory problem. In reality, the factory is just the first place where all the earlier decisions are forced to coexist.
That is why the goal is not to make QC work harder.
The goal is to make better decisions early enough so QC is not forced to rescue the product later.
A good PRD is not paperwork.
It is the first quality control document in the entire hardware NPI process.
Before engineers choose components, before industrial designers shape the product, before suppliers quote anything and before the factory builds a sample, the team needs to understand what the product must actually do.
Not just what the founder wants.
What the user needs. What the market expects. What the product must survive. What price point needs to be protected. What certification requirements are non-negotiable. What user experience cannot be compromised. What cost structure needs to exist for the business to work.
If the PRD is vague, quality has no direction.
You cannot validate quality against feelings.
You need requirements.
When the PRD is unclear, everyone starts optimizing for a different product.
The founder optimizes for the vision. The industrial designer optimizes for the object. The engineer optimizes for making it work. The supplier optimizes for what is easy to source. The factory optimizes for what is easy to assemble.
Nobody is necessarily wrong.
But the product starts drifting.
And that drift becomes a quality problem later.
This is where founding intent often gets diluted during NPI. The product might still work, but it no longer protects the reason customers wanted it in the first place.
A strong PRD gives quality a direction. It turns “make it good” into real constraints: target cost, use case, reliability, environment, certification, user experience and non-negotiables.
A lot of founders enter NPI after validating a market promise.
Maybe customers loved the prototype. Maybe investors backed the product. Maybe distributors showed interest.
That market promise is valuable. But in hardware, it still has to survive industrial reality.
Can the product be built repeatedly? Can it hit the target retail price? Can the margin survive distribution? Can the user experience survive value engineering? Can the product pass certification? Can it be assembled, tested, packed and shipped without turning every batch into a custom operation?
This is why PMF is not fully protected until it has been translated into product requirements, cost targets and manufacturing constraints.
The founder’s job is not to fight every tradeoff.
Tradeoffs are inevitable.
The founder’s job is to make sure every tradeoff is filtered through the product experience and PMF that made the product worth building.
A prototype can work perfectly and still be built on the wrong foundation.
This is one of the most expensive traps in hardware.
The demo works. The product turns on. The video looks good. The first users understand the concept. The team feels close to production.
But a proof-of-concept only proves that the idea can work once.
It does not prove that the product can be built repeatedly, at the right cost, with stable quality, under certification constraints, with real suppliers and real production variation.
That gap is where many hardware projects lose months.
Sometimes the architecture is technically clever but commercially impossible. Sometimes it is cheap on paper but expensive in assembly. Sometimes it works for five prototypes but creates failure modes at five thousand units.
This is why architecture review is not just engineering work.
It is quality work.
I once saw a product where the team thought they had made a very cost-efficient architecture choice during development.
On paper, it looked smart.
The BOM was low. The product worked. The prototype did the job.
But the architecture created constant instability in production. Assembly was sensitive. Testing was painful. Yield was inconsistent. The product needed too much attention unit by unit.
The company tried to compensate by throwing more QC at the problem.
More inspection. More sorting. More rework. More factory time. More people checking units before shipment.
But they were losing money on every unit shipped.
That is death by a thousand cuts.
You are not only failing to protect your margin. You are burning the cash you need to fuel growth. The more you scale, the more damage you create.
That is not a QC problem.
That is an architecture and NPI problem that was allowed to reach production.
A good architecture does not only make the product work.
It makes the product buildable, testable, certifiable and repeatable.
That means thinking early about power consumption, thermal behavior, wireless performance, component availability, assembly method, test access, firmware stability, repairability, certification risk and production yield.
These topics do not sound as exciting as product features.
But they decide whether the product can become a business.
The right time to challenge architecture is before design lock.
Not after tooling.
Not during PVT.
Not when the first shipment is already late.
Once the wrong architecture is baked into the product, QC can only show you how expensive the decision was.
The BOM is not just a list of parts.
It is a map of future problems.
A component can be technically correct and still be a terrible production choice.
Maybe the lead time is too long. Maybe the supplier is unstable. Maybe there is no approved alternative. Maybe the MOQ does not fit the launch plan. Maybe the cost only works at fantasy volume. Maybe the part is available today because a broker happens to have stock, but nobody can guarantee it six months from now.
That is not just a sourcing issue.
It is a quality risk.
Because when the BOM is weak, the product is fragile before production even starts.
A serious BOM review should not only ask whether the component works.
It should ask whether the component can support production.
Can we source it reliably? Can we approve an alternative? Can we control the supplier? Can we trace the part? Can we keep the cost stable at real volumes? Can we test it properly? Can we continue production if supply changes?
This is where approved vendor lists, second-source strategies, lifecycle checks, MOQ planning and component risk classification matter.
Founders often see this as purchasing detail.
It is not.
It is part of manufacturing quality.
A product built on an unstable BOM is already unstable before the factory builds the first unit.
We see this pattern often.
A team believes the design is locked, then discovers that a critical component cannot be sourced reliably at the right cost, in the right quantity, with the right traceability.
So the team starts changing parts late.
One component changes. Firmware needs to be adjusted. Mechanical tolerances shift. Certification risk changes. Validation has to be reopened. The schedule moves. The cost moves. The factory is blamed.
But the real issue was upstream.
The BOM was never production-ready.
A scalable BOM protects more than cost. It protects lead time, production stability, quality consistency and the ability to keep building the product without improvising every batch.
Review it while you can still change it cleanly.
Founders often separate cost and quality.
In real hardware manufacturing, they are connected.
Cost pressure changes behavior. When margins are too thin, teams start making decisions they would normally reject.
A cheaper supplier becomes acceptable. Validation gets compressed. A component alternative is approved too fast. Pre-compliance is delayed. Tooling fixes are pushed to the next batch. The pilot run gets shortened because cash is tight and the launch date cannot move.
None of these decisions looks catastrophic in isolation.
Together, they create a product that depends on luck instead of process.
This is where many hardware companies get trapped.
They are shipping, but they are not scaling.
Every unit creates stress. Every batch needs intervention. Every shipment eats cash. Every quality issue reduces the money available for marketing, inventory, support or the next production run.
That is not growth.
That is controlled bleeding.
This is why design-to-cost needs to happen early.
Design-to-cost does not mean making the product cheap. It means designing the product so the cost structure supports the business model.
The product has to protect user value, margin, quality and manufacturability at the same time.
That requires discipline.
Target retail price, channel margin, gross margin, BOM cost, tooling cost, assembly cost, testing cost, packaging, logistics and warranty risk all influence the quality decisions you can afford later.
If those numbers do not work, quality will eventually pay the price.
Value engineering is often misunderstood.
It is not cutting corners.
Good value engineering asks: what does the customer actually value, what does the product really need to do, where are we over-engineering, where are we adding cost without adding value, and where can we simplify the product without damaging the experience?
Done early, value engineering improves the product.
It can reduce assembly steps, simplify tooling, improve sourcing, remove unnecessary complexity and protect the margin structure.
Done late, it becomes damage control.
There is a big difference between reducing cost intelligently and cutting corners under pressure.
One protects quality.
The other quietly destroys it.
A common mistake is to involve manufacturing too late.
The team finishes the design, prepares files, sends them to suppliers and asks the factory to build the product.
It sounds logical.
It is usually expensive.
Manufacturing needs to influence the product before design freeze.
That is the role of DFM: Design for Manufacturing.
For electronic products, this often also means DFA, Design for Assembly, and DFT, Design for Test.
These are not factory formalities. They are NPI disciplines that protect quality, cost and repeatability before production starts.
Assembly sequence, tolerances, materials, tooling strategy, fixtures, test points, packaging, process flow and inspection strategy are not small factory details.
They are product decisions.
A screw hidden under a fragile cosmetic part is a product decision. A housing that cannot be opened cleanly for repair is a product decision. A tolerance stack-up that makes assembly unstable is a product decision. A product that needs manual adjustment on every unit is a product decision. A beautiful finish that cannot survive real production variation is a product decision.
These decisions affect cost, quality, yield, lead time and repeatability.
The factory can help you build the product.
But it cannot easily save a product that was never designed to be manufactured.
DFM should not happen after the product is already frozen.
By then, the options are limited and every change has a cost.
If manufacturing discovers the product at the end, manufacturing will also discover the problems at the end.
And that is the most expensive moment to find them.
A proper NPI process brings manufacturing constraints into product development early enough to shape the design, not just complain about it later.
That is how you protect quality before the factory has to prove whether the design was ready.
A working sample is not enough.
One unit working once under controlled conditions does not mean the product is ready for real users, real environments, certification, shipping, retailers or production variation.
This is why EVT, DVT and PVT exist.
They are not bureaucracy.
They are how hardware teams replace belief with evidence.
EVT checks whether the engineering works.
DVT checks whether the design meets the product requirements.
PVT checks whether the production process can build the product repeatedly.
Each stage has a different job.
If you skip one, you do not skip the risk.
You just move it downstream.
And downstream is where risk becomes more expensive.
Customers find it. Retailers find it. Support teams find it. Investors find it. Your cash flow finds it.
A good validation plan shows whether the product survives real use, whether firmware remains stable, whether the product can pass certification, whether operators can assemble it repeatedly, whether the factory can test it properly and whether the process produces stable units.
Depending on the product, this may include reliability testing, environmental testing, drop testing, aging tests, battery tests, thermal checks, pre-compliance, pilot builds, failure analysis and process capability checks.
Validation is not there to slow the project down.
It is there to stop the wrong product from moving too fast.
The faster a hardware company wants to scale, the more disciplined validation needs to be.
Testing should not be improvised on the factory floor.
If the team waits until production to decide what to test, how to test it and what pass or fail means, quality becomes inconsistent from the start.
This is how defects escape.
Not because nobody cared, but because nobody built the system properly.
For electronic products, production testing needs to be considered early. The PCB may need test points. Firmware may need a factory test mode. The product may need calibration. Fixtures may need to be designed. Test limits need to be defined. Results need to be recorded. Failures need to be tracked.
This is not admin.
This is part of the product.
A test that is too weak lets defects escape.
A test that takes too long kills line efficiency.
A test that records no useful data teaches you nothing.
A test that nobody owns becomes theater.
The goal is not to test everything forever.
The goal is to design the right quality control system for the product, the risk and the production volume.
Before production starts, the team should know what will be tested, where it will be tested, what equipment is needed, what “pass” means, how failures will be recorded and who reacts when the same defect repeats.
That may include incoming quality control, in-process quality control, functional testing, reliability sampling, final inspection, AQL sampling and outgoing quality control.
The exact setup depends on the product.
But the principle is the same.
If the test strategy is unclear, the product is not ready to scale.
QC matters.
But QC is not the quality plan.
Final inspection can catch visible defects. It can reject units. It can protect a shipment. It can confirm whether the production system is behaving within acceptable limits.
But QC cannot compensate for weak requirements, bad architecture, unstable components, poor DFM, vague acceptance criteria or missing validation.
QC should confirm that the system is working.
It should not be the first moment where the team asks what “good” means.
This becomes very obvious with cosmetic quality.
Founders often assume cosmetic expectations are obvious.
They are not.
Color, texture, scratches, gaps, flash, sink marks, assembly marks, printing alignment and packaging condition all need standards.
If nobody defines the limit, every inspection becomes a debate.
The founder says it is unacceptable. The factory says it is normal. The supplier says it is within tolerance. The customer says it looks cheap.
This is why golden samples, defect boards, inspection standards and clear AQL criteria matter.
Not because documentation is beautiful.
Because ambiguity is expensive.
AQL, cosmetic standards, functional criteria, defect classification and shipment approval rules are how the team avoids debating quality at the worst possible moment.
Use QC to confirm a strong system.
Not to rescue a broken one.
Certification is often treated as a separate workstream.
That is a mistake.
For many hardware products, certification is a quality constraint from day one.
CE, FCC, UKCA, RoHS, REACH, UL, RED, EMC, safety, battery transport, wireless requirements and product-specific standards are not forms to complete at the end.
They influence architecture, component selection, PCB layout, enclosure design, materials, labeling, documentation, testing and sometimes even the user experience.
If certification enters too late, the team may discover that the product needs design changes after it was supposed to be locked.
That is where timelines break.
A product that works but cannot pass certification is not production-ready.
This is one of the painful realities of hardware: technical success is not the same as market readiness.
The product has to work, pass, ship and comply.
Pre-compliance is not there to create another checkbox.
It is there to detect certification risk while the team can still do something about it.
It gives the engineering team a chance to adjust before the official test report turns into a schedule problem.
Certification planning is quality work.
It protects the product before the official lab tells you what already went wrong.
Quality does not always fail in one big moment.
Sometimes it drifts.
A supplier changes material. A component gets swapped. Firmware is updated. Tooling is modified. Packaging changes. A fixture wears out. A test limit is adjusted. Documentation falls behind production reality.
At first, nobody notices.
Then yield drops. Returns increase. Cosmetic defects appear. One batch feels different from the golden sample. A customer asks why the new units do not behave like the approved ones.
This is where change control matters.
Without proper control, the product slowly moves away from the version that was approved.
The golden sample says one thing. The production line does another. The documentation is outdated. The supplier made a change. The factory adjusted something to keep the line moving.
Nobody had bad intentions.
But the product changed.
That is enough to create a quality problem.
Revision control, approved alternates, golden samples, ECN processes, supplier approval, production records and clean documentation are not administrative details.
They are how you stop the product from becoming something else batch after batch.
Every serious production system needs to know what changed, who approved it, whether it was tested, whether the golden sample was updated, whether the factory documentation changed and whether the customer needs to know.
Without change control, quality slowly becomes luck.
And luck does not scale.
The job does not end when mass production starts.
Production data matters.
Yield issues, defects, assembly pain, supplier variation, test failures and customer returns are not noise.
They are signal.
The question is whether the system knows how to use that signal.
A good manufacturing quality system sends information back to the right place.
If a defect repeats, engineering needs to know. If a supplier issue appears, purchasing and quality need to act. If customers return units for the same reason, the product team needs to understand whether the problem is design, process, use case or communication.
Without that loop, the same problems repeat.
The factory blames the supplier. The supplier blames the design. The founder blames the factory. The customer blames the brand.
But the real issue is usually upstream.
Quality was treated as an inspection step instead of a product system.
A strong NPI and manufacturing process closes the loop between engineering, suppliers, production and customer feedback.
That is how the product improves.
Not through hope.
Through data, discipline and controlled decisions.
Most founders ask:
“How do we make sure the factory checks everything before shipment?”
That is the wrong starting point.
It focuses on the moment where defects become visible.
But visible does not mean fixable.
At that point, the tooling may be done. The components may be purchased. The packaging may be printed. The retailer may be waiting. The cash may already be committed.
Final QC can tell you what failed.
It cannot always give you a clean way out.
The better question is:
“How do we make sure the product, the process and the supply chain are designed so quality is repeatable?”
That question changes everything.
It changes how you write the PRD. It changes how you select components. It changes when manufacturing gets involved. It changes how you review architecture. It changes how you plan EVT, DVT and PVT. It changes how you design production testing. It changes how you define QC. It changes how you control changes after production starts.
This is where QC becomes useful.
Not because it magically saves the product.
Because by then, you know what you are checking, why you are checking it, where the risks are, what failure modes you already saw during development, and what the product is supposed to look like when the system is under control.
You arrive at QC with months of learning already baked into the quality plan.
That is very different from showing up at final inspection and hoping the factory catches whatever the product team forgot to validate.
Once the wrong decisions are baked into the product, inspection can only show you the damage.
If you are lucky, the issue is only craftsmanship: a scratch, a mark, a bad assembly gesture, a handling problem, something the factory can correct with training, inspection or process discipline.
But hardware is not usually that generous.
The thing you did not define, test, validate or control earlier is usually the thing that comes back later.
That is Murphy’s law in product development.
The weak requirement becomes the wrong design choice.
The skipped validation becomes the field failure.
The late component change becomes the certification problem.
The unclear cosmetic standard becomes the shipment dispute.
The missing test point becomes the production bottleneck.
Quality is not one heroic action at the end.
It is a chain of disciplined decisions made early enough to shape the outcome.
That is where quality really lives.
Not at the end of the line.
Much earlier.
Need a partner who knows how to engineer, industrialize and scale high-requirement products?
Reach out to hello@sprnv.com.
.svg)
.svg)
.svg){kind=icon}
