I've noticed that most hardware teams don't struggle gradually. They hit a cliff.
A big portion of that is that startup founders run to production — and that makes sense, because until you start producing units (and selling them) you aren't generating revenue. But the rush to manufacturability generates a ton of technical debt. The mass-produced products end up full of bugs, and the company may fail because of it.
The Technology Readiness Level (TRL) system was developed to help avoid exactly this kind of problem. The catch: it's mostly only used in large aerospace and defense firms. So I decided to apply TRL specifically to IoT products.
Gauging your TRL helps you decide when you should actually start selling. Getting to TRL 9 will involve working with customers and deploying at their sites — the nuance is in how you frame those deployments and whether they are paid or not.
TRL 1–3: Concept and Feasibility
Traditional definition: Basic principles observed and proven analytically or experimentally.
IoT startup reality:
- Core idea validated on paper (or screen)
- Key components identified (MCU, radio, sensors, power)
- Block diagrams
- Early firmware experiments
- Bench-level connectivity tests
- No real integration yet
What success actually looks like: You understand the technical risks. You know what might fail. Nothing is production-ready.
TRL 4: Integrated Prototype (Bench Level)
Traditional definition: Component validation in a lab environment.
IoT startup reality:
- First integrated prototype
- Custom PCB or dev board stack
- Firmware, radio, and sensors working together
- Cloud ingestion works in controlled conditions
- Manual flashing, manual configuration
Common misconception: "This is almost ready."
Reality: This is where many startups raise their first serious round — but the system is fragile and highly manual.
TRL 5: Relevant Environment Testing
Traditional definition: Component validation in a relevant environment.
IoT startup reality:
- Devices tested outside the lab
- Early field trials
- Connectivity variability appears
- Power consumption issues emerge
- Edge cases start dominating behavior
What changes here: The environment becomes a stakeholder. Failures become intermittent and harder to debug. Observability suddenly matters.
TRL 6: System Demonstration
Traditional definition: System or subsystem model demonstrated in a relevant environment.
IoT startup reality:
- Pilot deployments with real users
- Contract Manufacturer is now producing test units
- Multiple devices in the field
- OTA updates attempted
- First customer feedback
- Early support burden begins
Key risk: The system works, but only because the team is compensating manually.
TRL 7: Operational Prototype
Traditional definition: System prototype demonstrated in an operational environment.
IoT startup reality:
- Dozens to hundreds of deployed units (exact scale depends on your use case)
- Manufacturing variability appears
- Firmware versioning becomes critical
- Support and ops load increases sharply
- Compliance questions start blocking sales
This is the inflection point: Technical success without operational structure becomes a liability.
TRL 8: Qualified System
Traditional definition: Actual system completed and qualified through test and demonstration.
IoT startup reality:
- Production-intent hardware
- Defined manufacturing process
- Repeatable provisioning
- Certification completed or underway
- Change control becomes mandatory
New constraint: Speed now depends on coordination, not engineering talent.
TRL 9: Proven at Scale
Traditional definition: Actual system proven through successful operations.
IoT startup reality:
- Hundreds to thousands of devices deployed
- Stable manufacturing and supply chain
- Predictable updates and support
- Measurable reliability
- Ops, engineering, and business stay aligned
At this stage: Failures are costly, visible, and reputational.