Most IoT device design projects don’t fail because of one bad decision. They stall in the gaps between vendors.

A schematic is finished at one firm, sent to a PCB house for layout, handed to a firmware contractor for the embedded code, then shipped to a contract manufacturer for assembly. Each vendor does competent work inside their own scope. The problem is that nobody owns the system. When something breaks, and on an IoT product something always breaks, the calendar pays for it.

This post is about the tax you pay at every vendor boundary, why IoT projects feel that tax harder than most, and what changes when design and manufacturing live under the same roof.

The handoff tax nobody budgets for

Every time a project moves between organizations, something gets lost in translation. Sometimes it’s a file format. Sometimes it’s a spec that one team treated as a hard constraint and another read as a suggestion. Sometimes it’s a footprint that looks right in the CAD library but doesn’t match the part the buyer actually sourced.

These don’t show up on a Gantt chart. They show up as a returned prototype, a revision spin, a week of email threads trying to figure out who owns the bug. Multiply that by four or five vendor boundaries and the schedule everyone agreed to in the kickoff meeting starts to drift.

The honest math on a typical split-vendor project: design takes the time it takes, plus a buffer for the layout shop to ask clarifying questions, plus a buffer for the firmware team to align on hardware revisions, plus a buffer for the CM to flag DFM issues that should have been caught earlier. Each buffer is reasonable in isolation. Stacked together, they’re often the difference between hitting a funding milestone and missing one.

Why IoT projects break harder than simple board builds

A consumer gadget with a microcontroller and a couple of sensors is one thing. A connected IoT product is another. You have firmware that has to match the hardware revision exactly. You have RF performance that depends on the PCB layout, the enclosure, and the placement of the antenna relative to other components. You have cloud connectivity assumptions baked into the firmware that have implications for power budget, which has implications for component selection, which has implications for board layout.

There are more handoff surfaces than a typical board, and each one is a place where one vendor’s assumption can quietly break another vendor’s design.

A few patterns that recur:

The firmware team writes against a hardware spec from week three of the design process. By the time prototypes come back, the hardware team has revised the pinout. Nobody wrote it down. Two days of debugging follow before anyone catches it.

The PCB layout passes DFM at the layout shop but the contract manufacturer’s pick-and-place line can’t handle a fine-pitch component without specific tooling. The board gets built but yields are poor. Nobody flagged it because the layout shop was checking layout rules and the CM was checking what landed in their queue.

The enclosure is designed in parallel with the PCB. The mechanical team and the electrical team don’t sync on antenna keep-out zones. The first units have measurable RF performance issues that only surface in certification testing, weeks later, when the schedule has no slack left.

None of these are exotic failures. They’re what happens when each vendor optimizes their own scope and nobody is responsible for the system.

What “under one roof” actually changes

When electrical design, mechanical design, firmware, PCB assembly, and cloud software all sit inside the same team, the feedback loop collapses.

DFM review happens during design instead of after. A layout engineer walks ten feet to ask the assembly technician whether a placement is going to cause problems. The firmware lead is in the same standup as the hardware lead, so a pinout change gets caught before it ships into a build. RF concerns get flagged the day the enclosure CAD goes out, not six weeks later in a certification lab.

This is what Evertech’s engineering services are built around. The same team that designs the schematic also handles the PCB assembly, the firmware, and (when the project calls for it) the cloud platform that the device connects to. Evertech’s own Autosight product line is built this way, which is part of how we know what we know: we ship our own IoT hardware, not just other people’s.

Single point of accountability is the underrated part. When something does go wrong, and on a complex IoT build something usually does, there’s no email thread to find the right person. The team that owns the design is the same team that owns the build. The root cause analysis happens in a meeting, not a finger-pointing exercise.

For products that need to meet specific compliance requirements (medical devices, industrial controls), the consolidation also simplifies traceability. Documentation flows through one quality system instead of being stitched together across four. If you’re building a regulated product, our PCB manufacturing for medical devices page covers what that looks like in practice.

When the multi-vendor approach still makes sense

Not every project benefits from consolidation. There are situations where splitting design and manufacturing across vendors is the right call.

Large companies with established in-house engineering teams already have most of the design discipline that consolidation provides. The schematic and layout work happens internally, the firmware lives in a dedicated software org, and they go to a contract manufacturer purely for build capacity. The handoff tax exists, but it’s well understood and well managed.

Mature products with stable BOMs are another case. If a design has been shipping for years and the revisions are minor, sending it to a low-cost assembler is reasonable. The risk of a handoff problem is lower because the design isn’t changing.

Where consolidation matters most is the case where this post started: an IoT product still working through prototype-to-production, a small or mid-sized hardware team, a schedule that can’t absorb multiple revision spins. If that’s your project, a partner that does design and manufacturing in one shop is almost always faster and lower-risk than stitching together specialists.

Questions to ask before splitting your IoT project across vendors

If you’re evaluating whether to use one partner or several, the answers to these questions will tell you most of what you need to know.

Who owns DFM, and when does it happen? If DFM review is the contract manufacturer’s job and it happens after layout is complete, you’re going to spin revisions. Look for a partner that does DFM during design.

How are firmware and hardware revisions synchronized? If the firmware team and hardware team are at different companies, ask specifically how revision control works between them. “We email each other” is not a process.

What happens when AOI testing flags a placement issue mid-production? A consolidated team can root-cause and fix in a day. A split-vendor setup will involve the assembler emailing the layout shop, the layout shop asking the design firm for clarification, and the design firm checking with the firmware team about whether a workaround is acceptable. That sequence takes a week.

Who debugs RF or thermal issues that span the PCB and enclosure? If the answer is “the customer,” that’s a problem. Someone needs to own system-level performance, not just the boards.

What does the documentation handoff look like for regulated industries? For medical, industrial, or any product that needs traceability, one quality system is dramatically simpler than four.

These questions don’t have to disqualify the multi-vendor approach. They just need clean answers. If they don’t get them, the timeline you’re being quoted is optimistic.

Get in touch

If you’re working through an IoT project and want to talk about what an integrated design and manufacturing approach would look like, we’re always happy to discuss. Whether you have a concept, a prototype that needs a path to production, or just questions about how the process works, you can reach us through the contact form on our homepage.