I've lost count of the number of times someone has put a working device on the table in front of me — usually a neat little box with a 3D-printed shell, a dev board inside, sensor data streaming to a dashboard — and asked how long it'll take to make ten thousand of them.
The honest answer is usually "longer than it took you to build that one, by a factor of five or ten." Not because the prototype was bad. Because a prototype and a product are different objects that happen to look similar.
This post is about the gap. If you're planning an IoT prototype to production transition in the next year, these are the things that will bite you, roughly in the order they show up.
A prototype proves the idea. It doesn't prove anything else.
Your prototype answers one question: does this concept work at all? That's a genuinely valuable answer and you shouldn't skip the step. But it says nothing about whether the device survives a drop test, passes radio certification, can be assembled by someone who isn't you, or still works when the WiFi module you used goes end-of-life in eight months.
The specific gap looks like this. A prototype is one unit, built by the person who designed it, in a room at 22°C, on a known network, with a debugger attached. A product is thousands of units, built by strangers, in a warehouse at 45°C, on a customer's badly configured router, with no debugger and no way to physically reach the thing once it ships.
Every one of those differences costs engineering time.
The five things that actually derail IoT production
1. Your bill of materials was never designed to be bought
Prototypes are built from whatever's in the drawer or whatever Digi-Key had in stock on a Tuesday. Production needs parts you can buy 5,000 of, at a price that leaves you margin, with a lifecycle guarantee.
What goes wrong:
- Single-source components. One vendor, one part number, no drop-in alternate. When that part allocates out to 40 weeks, your product line stops.
- Dev-board-grade parts. Modules designed for hobbyists often have no long-term availability commitment. Industrial-grade equivalents cost more and you should budget for them.
- Price at quantity one. That ₹450 sensor might be ₹180 at 5,000 units — or it might be ₹440, because nobody negotiated. You don't know until you ask.
Do a BOM scrub early. For every line item, write down the second source. If you can't find one, that's a design decision you need to revisit, not a purchasing problem for later.
2. Certification is a real project, not a formality
Anything with a radio in it needs to pass regulatory testing in every market you sell into. FCC in the US. CE/RED in Europe. UKCA. Plus safety, and depending on the product, environmental directives.
Two things surprise people. First, the cost — for a straightforward WiFi/BLE device, testing typically lands somewhere in the several-thousand-dollars range per market, and considerably more if you designed your own radio rather than using a pre-certified module. Second, the schedule. Lab slots get booked. A failure means a board respin and a re-test, and now you're three months behind.
The single biggest lever here is using a pre-certified radio module instead of a bare chipset. You give up some board space and some margin per unit. You save an enormous amount of certification risk. For most products under a few tens of thousands of units a year, that's the right trade. I say this as someone who enjoys RF design — it's just rarely the thing worth spending your runway on.
3. Nobody designed a way to program and test the units
This is the one people forget entirely. On the factory floor, someone has to take a bare board and, in under a minute:
- Flash the firmware
- Write a unique device ID and cryptographic credentials
- Run a functional test — does the sensor read, does the radio transmit, does the LED light
- Calibrate anything that needs calibrating
- Log the result against the serial number
That needs a test fixture, a test harness, and a provisioning system. It is a real piece of engineering work — often several weeks — and if you haven't scoped it, your contract manufacturer will either quote you a fortune for it or shrug and ship untested boards. Neither is good.
Related: how do you get unique keys onto each device without a human being able to read them? If your plan is "same credentials on every unit," you've built a product where one compromised device compromises the entire fleet.
4. Firmware updates are the feature you'll need most and plan least
You will ship a bug. Everyone does. The question is whether you can fix it without a truck roll.
Over-the-air update needs to be in the architecture from day one, not bolted on. That means dual-bank flash (so a failed update doesn't brick the unit), signed images, rollback on failure, and a staged rollout so a bad build doesn't take down your whole fleet at once. It also means your bootloader is now a critical piece of software that has to be right.
Budget the flash for it. Retrofitting OTA onto a part with 256KB of flash and no spare bank is a miserable exercise.
5. Power and thermals behave differently in the real world
Battery life calculated on a spreadsheet and battery life measured over a winter in Manchester are different numbers. Cold kills lithium capacity. Poor cellular coverage means the modem transmits at higher power and stays awake longer. A sleep current of 40µA becomes 2mA because of one leaky pull-up nobody noticed.
Measure real current draw on real hardware, over real duty cycles, at the temperature extremes your device will actually see. Then add margin.
The honest question: do you need custom hardware at all?
Here's the part most hardware firms won't tell you. A lot of IoT projects don't need a custom PCB.
If your volumes are under a few thousand units, or you're still validating the business model, there's a strong case for building on off-the-shelf industrial hardware — a commercial gateway, a certified sensor node, a ruggedised single-board computer — and putting all your effort into the firmware, the cloud platform, and the analytics layer. That's where the differentiation usually lives anyway.
You'll pay more per unit. You'll ship six to twelve months sooner, skip most of the certification work, and avoid tying up capital in inventory before you know what the market wants. Go custom when the unit economics demand it, when you need a form factor nothing off-the-shelf provides, or when you've proven demand and volume justifies the NRE.
I've talked clients out of custom boards more than once. It usually turns out to be the right call.
What a realistic plan looks like
For a moderately complex connected device going from working prototype to shippable product, a typical path runs something like this:
- Design for manufacture review — component sourcing, second sources, DFM/DFT feedback on the layout
- Engineering validation build — a small run, usually 10–50 units, to shake out assembly and functional issues
- Pre-compliance testing — cheaper informal RF and EMC testing to catch problems before you book the real lab
- Design validation build — a few hundred units, environmental and life testing, real field trials
- Formal certification
- Production validation build — first run on the real line, with the real fixtures
Realistically that's nine to eighteen months for most teams, and the schedule is driven more by lead times and lab availability than by engineering effort. Plan two board respins. You'll probably need them.
Where the software side quietly gets expensive
The device is half the product. The other half — fleet management, provisioning, telemetry ingestion, alerting, the customer-facing app — often ends up being the larger engineering spend and the part that determines whether customers renew.
Be deliberate about cloud costs per device per month. Multiply by your target fleet size. A few cents of message ingest looks harmless until you have 50,000 devices reporting every thirty seconds. Edge filtering — deciding on-device what's worth transmitting — is usually the cheapest optimisation available, and it's where lightweight on-device models can earn their keep. If that's relevant to what you're building, our AI & ML development work often starts exactly there.
The short version
Going from IoT prototype to production isn't a scaling problem, it's a different engineering problem. Sourceable BOM, pre-certified radios, real test fixtures, OTA from the start, measured power, and an honest conversation about whether custom hardware is even necessary. Get those six right and the rest is schedule management.
If you've got a prototype on the bench and you're trying to work out what the real path to shipping looks like — including whether you should build custom hardware at all — get in touch. Happy to look at your design and give you a straight assessment, and you can see the kind of work we do over on our work page.