I’ve had this conversation more times than I can count. An engineer or founder holds up a board, a module, a firmware build, and asks: “Is this production-grade?” They’re looking for validation. What they usually get from me is a question back: good enough for what, exactly?
That question isn’t deflection. It’s the whole answer.
“Production-grade” sounds like it should be a fixed bar, a line between the amateur and the professional, between the prototype and the product. In practice, it isn’t. The bar moves depending on what you’re building, who’s using it, under what conditions, and what happens when something fails. A design that’s entirely appropriate for a consumer wellness gadget would be completely unacceptable for a class II medical device. The same PCB, the same chip, the same firmware architecture. Different bars.
This sounds obvious when you say it out loud. But I see the confusion play out in real projects all the time, usually in one of two directions.
The first is mistaking component grade for engineering quality. The idea that using industrial-rated components, a metal enclosure, and ruggedized connectors makes something production-grade. That’s not wrong exactly, but it’s backwards. A device built with commodity parts, with proper test coverage, well-defined error states, and a firmware architecture that fails gracefully, is more production-grade in any meaningful sense than a device built with expensive parts and no real test plan. Component selection matters, but it’s downstream of understanding what the product actually needs to survive.
The second confusion is treating “production-grade” as something you achieve once rather than a bar you define up front. Teams hit a milestone, first functional prototype, successful demo, initial field units, and start using the phrase as though crossing it ends something. It doesn’t. It describes a target: this design, in this use case, meets the requirements we defined for it. If those requirements were never written down, the phrase is just noise.
The requirements are the hard part, and they’re much more specific than most people expect.
For a consumer IoT product, you’re looking at FCC and ISED certification, CE if you’re selling into Europe, a reliability spec for the operational environment, and a firmware architecture that handles OTA updates, crash recovery, and power cycling without corrupting state. That’s real work, and it’s not trivial. But it’s scoped.
For a medical device, even a wellness wearable at the lower end of the regulatory spectrum, the scope expands significantly. Software needs to follow IEC 62304, you’re building a design history file, and every design decision needs traceability to a written requirement. The same firmware build that would ship fine in a consumer context requires a formal risk management process underneath it.
For an industrial control system, or anything in an automotive application, the standards shift again. ISO 26262 for automotive. IEC 61508 for functional safety in industrial settings. Neither of these is something you bolt on after the fact. They shape the architecture from the start.
The cost difference between these levels is real. A consumer FCC/CE filing typically runs $10,000 to $30,000 depending on what’s in the device and how clean the first submission is. Adding IEC 62304 compliance to a firmware project can double the engineering hours. Over-engineering to the wrong standard wastes money. Under-engineering to the right one creates liability.
None of this is a reason to avoid the question. It’s a reason to answer it properly from the beginning.
What I find in practice: the projects that go well are the ones where someone sits down early, before the first schematic, before the first line of firmware, and writes a short answer to a few concrete questions. What failure modes are unacceptable? What’s the operating environment? What regulatory category does this product fall into? What does reliability mean, in numbers? A device with a ten-year field life under outdoor conditions has different requirements than a device that sits on a desk and gets replaced every two years. Writing that down changes what you build.
The projects that struggle are the ones where “production-grade” gets used as shorthand for “we want this to feel professional” without anyone translating that feeling into specific requirements. Those projects usually produce something expensive and late that doesn’t quite hit the bar, because the bar was never actually drawn.
There’s a version of this that shows up on the component side too. I’ve seen clients spend significantly more on component grades than the use case warranted: industrial temperature range parts for a product that will never leave a climate-controlled office, ENIG finish on boards where HASL would have been fine. That money would have been more useful in actual testing, failure mode analysis, or certification preparation. Signaling quality through expensive parts is a real thing, but it doesn’t substitute for the engineering work that creates genuine reliability.
The honest definition of production-grade: a design where the acceptance criteria are specific, the testing covers the failure modes that actually matter for this use case, the regulatory requirements for this product category have been met, and someone can explain in writing why each of those bars was set where it was. That’s it. It applies to a $50 IoT sensor and a $5,000 medical instrument. The bar is different. The process of setting it, clearly and early, is the same.