The terminology around IoT product development is a mess. ODM, OEM, CM, EMS, ODM-EMS, design house, contract shop. People use these terms loosely and sometimes interchangeably. The result: companies buy the wrong engagement model, discover the gap six months in, and pay to switch.
This is a practitioner guide. We will define the terms the way they are actually used in IoT, walk through when each one fits, and give you a decision tree you can run in a meeting. We built an IoT ODM (that is what OmnIoT does), so our bias is visible. Where it matters, we will say so.
The terms, defined once
Contract Manufacturer (CM), also called Electronics Manufacturing Services (EMS). Assembles hardware to a design you provide. You give them schematics, a bill of materials, test procedures. They source parts, populate boards, assemble enclosures, run test fixtures, ship you units. They are a manufacturing service. They do not design the product.
Examples: Jabil, Foxconn, Flex, Celestica, dozens of regional shops. Also includes “box build” CMs that assemble complete mechanical-electrical-firmware packages from your files.
Original Design Manufacturer (ODM). Designs and manufactures a product, handing you a finished thing to sell under your name. In consumer electronics, this is how most laptops, earbuds, and cheap electronics get built: a Taiwan or Shenzhen ODM designs a reference product, multiple brands buy slight variations, and the brand’s only contribution is the logo and the sales channel.
In IoT, the scope is usually larger than just the hardware. An IoT ODM typically delivers hardware, firmware, a cloud tenant, and branded mobile apps as one package. This is because IoT products are software-heavy, and a hardware-only “ODM” leaves the biggest cost in the buyer’s lap.
Original Equipment Manufacturer (OEM). Term abuse central. In consumer electronics and old-school industrial, OEM sometimes means the ODM. In modern industrial and automotive, OEM usually means the company selling the final product to end customers, not the company that makes it. In IoT marketing, OEM is sometimes used to mean “large industrial customer who buys components and integrates them.” Clear as mud. We recommend not using the term at all unless the counterparty has already used it in a specific way.
Platform SDK. Not an engagement model, but people conflate it with ODM so it belongs here. Platforms like Particle or Golioth sell you firmware libraries, sometimes hardware, and a cloud API. You build the product on top of those primitives. They are not in the ODM category; they are in the “build it yourself, with help” category. For a full treatment of this trade-off, see our post on the real cost of building on AWS IoT Core and its cousins.
Bespoke engineering firm. Sometimes called a “design house” or “contract engineering firm.” Writes custom firmware and cloud against your spec, charged by the hour or by project. Differs from an ODM because there is no underlying platform being licensed: every line of code is bespoke, and the maintenance burden lands on you after launch.
The decision, simplified
Here is the question that sorts most teams into the right bucket:
Do you have engineers who will own this product’s firmware, cloud, and mobile apps for the next five to ten years?
If yes, you need a contract manufacturer. You have the engineering. You just need manufacturing capacity. Your engineers write the firmware, your cloud team runs the backend, your mobile team ships the apps. The CM prints boards, assembles enclosures, runs tests, ships units. Done.
If no, and you have no plans to hire that team, you need an ODM. Someone has to run all those functions. If it is not your team, it is the ODM’s team, and you pay for that service in the engagement fee.
If no, but you will hire that team over the next 6 to 18 months, you are in an uncomfortable middle zone. A bespoke engineering firm can bridge you to production, but you will inherit the maintenance burden when your team arrives. A platform SDK can give your arriving engineers a head start without locking you in. A full ODM might be overkill if you will eventually own the stack. Pick based on how patient your investors are and how confident you are the hiring will succeed.
The hybrid model
Large IoT programs often end up splitting the engagement. Early stages look like an ODM; late stages look like a CM plus a licensed software stack.
A typical progression:
- Year 1: ODM designs the product, runs early production out of a partner manufacturer, delivers firmware and cloud. Total units: hundreds.
- Year 2: Volumes grow past 3,000 to 10,000 units. The ODM’s production partner is no longer the cost-optimal choice. The buyer qualifies a dedicated CM, ports the hardware BOM over, and runs higher volumes there.
- Year 3+: CM makes the hardware. ODM keeps running the firmware, cloud, and mobile apps as a licensed platform plus SaaS. Two separate vendor relationships.
This is a stable long-term structure. Your hardware costs reach bottom via the CM, your software stack stays maintained by the ODM, you never have to hire the in-house team, and you own the product IP in terms of brand and customer relationships.
The common trap is trying to do this hybrid from day one, before the product has proven itself. The coordination overhead between an ODM and a CM on a product still finding its form is brutal. Pick one engagement model for year one, split only once the product is working.
Cost, honestly
A real comparison has to account for total cost over time, not just the quoted engagement number. Here is a rough shape for a mid-volume commercial IoT product (say, 500 units in pilot, scaling to 3,000 units in production over two years), with no bespoke sensor work required.
| Cost element | Contract manufacturer path | IoT ODM path |
|---|---|---|
| Year 1 engineering (firmware, cloud, mobile) | $700k to $1.5M (your team) | $80k to $250k (ODM NRE) |
| Hardware unit cost at 500 units | Varies; CM has BOM advantage at scale | Similar at low volume |
| Hardware unit cost at 3,000 units | Possibly 10 to 20% lower than ODM | Higher per unit |
| Cloud + mobile SaaS, Year 1 | Your hosting + team cost | Per-device or per-user SaaS fee |
| Year 2+ engineering maintenance | $500k to $1M per year | Included in SaaS fee |
| Risk of schedule slip in Year 1 | High (first build always slips) | Moderate (platform already exists) |
| Maintenance burden | Yours, forever | ODM’s |
The CM path has lower per-unit cost at scale, and lower total cost over time only if the engineering team you hire actually ships and actually maintains the product. In practice, the top-heavy engineering cost of the CM path is where most connected product attempts die. Teams spend 18 to 24 months building infrastructure that every other IoT company already has, run out of patience or funding, and never reach a product.
The ODM path has higher per-unit cost at scale, but avoids the Year 1 engineering cliff. If your product works and you are selling in Year 1, the ODM path has already paid for itself.
The questions to ask a potential ODM
Not every company calling themselves an IoT ODM is one. Some are contract engineering firms charging monthly. Some are platform SDKs with a services arm. Some are CMs that added a software partner and started calling the bundle an ODM.
Five questions that separate the real ones:
- What is your platform, and can I see it running in production today? Real ODMs have a shared platform they have already invested in. If the answer is “we will build one for you,” you are buying bespoke engineering, not an ODM engagement.
- Do you deliver mobile apps published in the App Store and Play Store under my identity? This is the hardest layer and the one that most “ODMs” skip. If the answer is “we deliver a mobile SDK and you publish,” the scope is narrower than you think.
- Is the cloud multi-tenant, and is my tenant on my domain? Single-tenant means they will build you a one-off backend. You want multi-tenant, because that is what is maintainable at low cost long-term.
- What is the ongoing per-device or per-user cost after launch? If they avoid the question, the costs are probably large and backloaded.
- Do you have a customer running in production at a similar volume to where I want to be in Year 2? References matter. Ask for them.
When to walk away
Three signs an ODM engagement is not right for you:
- You need consumer-scale volume. Above 30,000 units per month, ODMs are not the right structural choice. Go to a large CM, hire engineers, amortize the costs.
- Your competitive advantage is in the infrastructure itself. If your product is the IoT platform, you cannot buy it from an ODM. Build it.
- You need complete IP ownership of every line of source. Possible with an ODM but expensive and usually ill-advised. Bespoke engineering firms are a better structural fit, at roughly 4 to 10 times the total cost.
If none of those apply, and you want to sell a connected product without running a firmware, cloud, and mobile team, an IoT ODM is almost certainly the right engagement model.
Where OmnIoT fits
Full disclosure: we are an IoT ODM. We designed and built a platform (hardware, firmware, cloud, mobile), and we license it plus deliver customized connected products under customer brands. We are good for commercial and industrial IoT, bad for consumer-scale and bad for novel infrastructure. We wrote the /odm page specifically to give potential buyers a clear view of what we do and do not fit.
If you are evaluating an ODM engagement, start a conversation here. If the decision tree above pointed you toward a contract manufacturer or a platform SDK, we will tell you during discovery; the least productive thing for both sides is an engagement that was never a fit.