PCB and firmware coordination — how do they manage the handoff between hardware design and software development? A strong team speaks both languages fluently.

🚩

Red flag

If they only talk code and show no awareness of hardware constraints, timing, or PCB-level concerns — walk away. Embedded without hardware context is a recipe for failure.

Do They Build for Real-World Conditions?

🔍

Ask about

Network instability — how does their firmware behave when connectivity drops mid-operation? Robust embedded systems must handle intermittent or absent networks gracefully.

🔍

Ask about

Edge cases — do they actively test for boundary conditions, unexpected inputs, and unusual device states? Real-world devices encounter situations no spec ever anticipated.

🔍

Ask about

Field failures — can they share examples of diagnosing and fixing issues found after deployment? A team with field experience thinks differently from one that only works in a lab.

OTA Strategy from Day One

🔍

Ask about

Rollback — if an OTA update bricks a device in the field, can the system automatically revert to the last stable firmware version? This is non-negotiable for production deployments.

🔍

Ask about

Versioning — how do they track and manage firmware versions across thousands of devices? A mature OTA strategy includes clear version control, staged rollouts, and audit trails.

🔍

Ask about

Failure handling — what happens when an update fails mid-transfer due to power loss or connectivity drop? A solid OTA system is designed to survive interrupted updates without corrupting the device.

Connectivity Expertise

🔍

Ask about

BLE, WiFi & MQTT — do they have hands-on experience with the protocols your product actually needs? Each has distinct constraints around power, range, latency, and reliability that require specialist knowledge.

🔍

Ask for examples

Request specific past projects where they implemented BLE pairing, WiFi reconnection logic, or MQTT broker communication. Vague answers like "yes we've done IoT" are not enough — push for real examples with context.

Power Optimization Capability

🔍

Ask about

Battery-powered device experience — for devices that run on batteries, power management isn't an afterthought, it's a core engineering discipline. Ask how they approach sleep modes, wake intervals, radio duty cycling, and current profiling. A team without this expertise will drain your battery — and your users' patience.

Scalability Thinking

🔍

Ask about

10 → 10,000 devices — can their architecture handle a 1,000× jump in fleet size? Firmware that works for a pilot batch often breaks under real-scale load. Ask how they design for device management, telemetry, and updates at scale from the very beginning.

Testing Process

🔍

Ask about

Long-duration testing — do they run devices for days, weeks, or months under simulated load? Memory leaks, thermal drift, and hardware wear only surface over time, not in a quick smoke test.

🔍

Ask about

Real-world deployment testing — have they tested in the actual environment your product will live in? Lab conditions never fully replicate factory floors, outdoor enclosures, or consumer homes.

Production Readiness

🔍

Ask about

PCB design support — can they assist with schematic review, layout guidelines, or DFM (design for manufacturability) feedback? Software-only teams often hand off at firmware, leaving hardware gaps unfilled.

🔍

Ask about

Enclosure & mass production — do they think beyond the prototype? A true embedded partner understands thermal management, IP ratings, regulatory certifications, and the realities of contract manufacturing.

🔍

Code Quality and Documentation

🔍

Ask about

Firmware structure — how do they organise their codebase? Look for modular architecture, clear separation of HAL and application layers, naming conventions, and inline documentation. Well-structured code is maintainable code — and maintainability is what protects you after handoff.

Communication & Ownership

🔍

Ask yourself

Do they think, or just execute? The best embedded partners don't wait to be told what to build — they proactively flag risks, propose better approaches, and take ownership of outcomes. If every conversation is purely transactional, they see themselves as a vendor, not a partner.

Red Flags to Watch Out For

🚩

"We'll figure it out later" attitude

Deferred decisions in embedded systems become expensive problems post-deployment. A serious partner plans for edge cases upfront, not after a field failure.

🚩

No mention of OTA updates

If OTA isn't part of their default conversation, your product will be stuck on v1.0 forever — or require costly recalls to update firmware in the field.

🚩

No production experience

Prototyping and production are entirely different disciplines. A team that has never shipped at scale will hit walls the moment you move beyond the lab.

🚩

Overpromising timelines

If they promise an unrealistically fast delivery without caveats, they either don't understand the scope — or they're telling you what you want to hear.

Final Thoughts

⏱️

The right partner saves months

Choosing well upfront eliminates costly rework cycles, integration failures, and the painful process of switching vendors mid-development.

🔗

Embedded decisions are hard to undo

Unlike software, embedded architecture is tightly coupled to hardware. A wrong architectural choice can mean a full board respin — not just a code refactor.

Talk to an Embedded Expert →