How to Select Right Custom Firmware Development Company - 6 Criteria

What happens if you choose the wrong firmware partner?

Your hardware prototype is ready. The PCB is back from fabrication, the BOM is locked, and now you need a firmware team to bring it to life. You've found three companies that all look credible on paper: case studies on the website, a technical team page, a reply within 24 hours.

Six months later, one of those companies delivers firmware that works on the bench but fails on production units. Another uses a FreeRTOS version with a known vulnerability. A third hands over a codebase with no documentation and a single developer who has since left the company.

By the end of this post, you'll have a concrete set of criteria to evaluate any custom firmware development company before you hand over your hardware or your IP. These are the criteria that separate a vendor who ships from one who stalls.

Why Firmware Vendor Selection Goes Wrong

Firmware development looks like software development from the outside. It isn't. A bad web development vendor delivers a slow website. A bad firmware vendor delivers a device that resets in the field, fails regulatory testing, or ships with a memory leak that compounds over 72 hours of uptime.

The consequences are hardware-level and often irreversible without a respin. A firmware bug that surfaces after 10,000 units are in the field costs far more than the original development contract.

Most vendor selection mistakes happen for one of three reasons:

• Portfolio over process: The vendor has an impressive case study list but no documented engineering process. Case studies show what they shipped, not how, and not whether it still works.

• Generalist over specialist: A software house that "also does embedded" is not the same as a team that lives in RTOS scheduling, interrupt latency, and low-power design. The gap shows up after the first hardware handoff.

• No IP or handoff clarity: The contract doesn't specify who owns the codebase, what gets delivered at the end, or what happens if the engagement ends early.

The seven criteria below are structured to catch all three failure modes before you commit.

Criterion 1: Evaluate the Depth of Their Embedded Portfolio, Not Just the Length

Every custom firmware development company has a portfolio page. The question is not how many projects are listed. It's what the projects actually required.

Look for specific technical claims. A portfolio entry that says "developed BLE firmware for a wearable device" tells you very little. A portfolio entry that describes implementing a FreeRTOS task architecture for concurrent sensor sampling and BLE data streaming, with OTA update support and a 12µA sleep current target, tells you the team understands what embedded development actually involves.

Questions to ask when reviewing their portfolio:

• What RTOS did they use and why? If they can't explain the trade-off between FreeRTOS and Zephyr for that specific project, they may not have made the choice themselves.

• What wireless protocols did they implement? BLE, Wi-Fi, LoRaWAN, and Zigbee each have fundamentally different stack architectures. A team that has only shipped Wi-Fi devices is not automatically qualified for a LoRaWAN deployment.

• What were the power requirements? Any battery-powered project should have a documented sleep current target. If they can't name it, ask why.

• Did they handle OTA updates? Firmware that cannot be updated in the field is a liability. Any vendor worth considering should have done this before.

• What was the regulatory path? CE, FCC, UL, or FDA involvement changes what the firmware needs to do. A vendor with no regulatory experience will create problems late in the process.

Criterion 2: Test Their Hardware-Firmware Integration Experience

Firmware doesn't run in a vacuum. It runs on a specific PCB, with specific peripherals, at specific voltages and temperatures. A firmware team that has only worked from someone else's hardware design will struggle when they encounter a real hardware-firmware integration problem.

The distinction matters most in these situations:

• Board bring-up: Validating that a new PCB revision works as expected, debugging the gap between schematic intent and actual hardware behaviour

• Peripheral debugging: I2C lockups, SPI timing violations, ADC calibration drift across temperature

• Power sequencing: Ensuring peripherals come up in the right order, with the right delays, without causing brownouts or unexpected resets

Ask the vendor directly: have they ever debugged a hardware issue during firmware development? What tools do they use: oscilloscope, logic analyser, JTAG debugger? A team that relies only on UART output for debugging is not equipped for production-grade embedded work.

On one connected industrial sensor project, a firmware team unfamiliar with hardware debugging spent three weeks attributing an I2C lockup to firmware logic. The actual cause was a pull-up resistor value that was marginal at the operating temperature range. An experienced embedded team with a logic analyser found it in four hours.

Criterion 3: Ask for Their Firmware Architecture and Review Process

The quality of a firmware codebase is invisible until it causes a problem. The way to make it visible is to ask the custom firmware development company how they structure and review code before you commit.

A mature embedded firmware team has answers to these questions before you ask:

• Do you use a defined RTOS task architecture? The answer should include how tasks are prioritised, how shared resources are protected, and what the interrupt hierarchy looks like.

• How do you handle OTA updates? The answer should include partition layout, image verification, rollback strategy, and what happens if a download is interrupted.

• What does your code review process look like? The answer should describe who reviews, what they review for, and what post-review testing is run before a build is considered stable.

• How do you detect and handle runtime faults? The answer should include watchdog configuration, HardFault handling, and what data is captured before a reset.

• What is your branching and versioning strategy? Any team shipping production firmware needs a documented process for managing releases, hotfixes, and feature branches.

If the vendor answers these questions in vague terms, or treats them as unusual questions, that is a signal their process is informal. Informal processes produce firmware that works until it doesn't.

What a mature firmware architecture process looks like:

• Post-code-review runtime testing: stack watermark profiling, memory leak detection, ISR timing validation

• Fault logging to flash before device reset, transmitted on next boot

• Defined sleep mode strategy with measured current targets at each power state

• Version string embedded in firmware, readable over the debug interface and OTA metadata

Criterion 4: Verify Their Wireless Protocol Expertise Matches Your Requirements

Wireless firmware is where the most expensive production failures happen. Bluetooth Low Energy coexistence issues, Wi-Fi reconnection logic under poor signal conditions, LoRaWAN duty cycle compliance, Matter certification requirements: each requires specific, deep experience to get right.

A vendor that has shipped BLE firmware for a consumer device is not automatically qualified to build a Matter-certified smart home product, even though both involve wireless connectivity. The certification requirements, stack architecture, and testing process are fundamentally different.

Ask the vendor to describe a specific wireless bug they found and fixed in a production product. The answer should include what protocol was involved, what the failure mode was, how they diagnosed it, and what the fix was. "Done a lot of BLE projects" is not a sufficient answer.

Criterion 5: Clarify IP Ownership, Code Handoff, and Documentation Standards

The firmware any custom firmware development company writes for you should belong to you. This sounds obvious. It often isn't, because firmware development contracts vary widely in what they define as deliverables.

Before signing any contract with a custom firmware development company, confirm:

IP ownership:

• Does the contract explicitly state that all firmware written for your project is your intellectual property upon payment?

• Are there any third-party libraries or RTOS components in the codebase that carry licence restrictions? MIT and Apache 2.0 are generally permissive. GPL can create complications for commercial firmware.

• Does the vendor retain any right to reuse your code architecture in other projects?

Code handoff deliverables:

• Source code in a repository you control, not a zip file on their server

• Build instructions that allow your team to compile and flash without vendor involvement

• Hardware abstraction layer structure documented so a new developer can orient quickly

• Any pre-compiled blobs or binaries documented with their source and licence

Documentation standards:

• Inline comments at the function level for non-obvious logic

• A firmware architecture document covering task structure, memory map, peripheral ownership, and interrupt priorities

• OTA update procedure documented from trigger to completion

• Known limitations and open bugs documented at handoff

On one medical device project, a firmware handoff included 12,000 lines of C with no architecture document, no inline comments on timing-critical sections, and three undocumented binary blobs from a third-party sensor vendor. Onboarding a new firmware engineer took six weeks instead of one.

Criterion 6: Evaluate Communication, Timeline Transparency, and Escalation Behaviour

Technical capability is necessary. It is not sufficient. The firmware development engagements that go wrong almost always have a communication failure alongside a technical failure.

Signs of a vendor with a mature communication process:

• They ask about your hardware before they quote. A vendor that quotes a fixed price for "BLE firmware development" without asking about the MCU, the peripheral set, the wireless protocol version, or the OTA requirement is quoting blind.

• They flag risks proactively. When a hardware issue delays firmware progress, a good vendor tells you the same day it becomes apparent, not at the next scheduled check-in.

• They provide weekly written status updates without being asked. Status should include what was completed, what is in progress, what is blocked, and what the next milestone is.

• They escalate problems before they become delays. A vendor that surfaces a technical blocker after two weeks of attempting to resolve it independently has cost you two weeks.

Red flags in early-stage communication:

• Vague responses to specific technical questions during the evaluation phase

• No pushback on your requirements (a good vendor will identify constraints you haven't considered)

• Reluctance to discuss their internal review process

• Quotes that don't break down into phases, milestones, or deliverables

How to Choose a Custom Firmware Development Company: Decision Checklist

Run through this before shortlisting any custom firmware development company.

Portfolio depth:

• Can they name the RTOS, protocols, and power targets for at least two projects?

• Do they have experience in your specific wireless protocol?

• Have they shipped firmware for a product in your industry vertical?

Technical process:

• Do they have a documented post-code-review testing process?

• Can they describe their fault handling and watchdog strategy?

• Do they use hardware debug tools (JTAG, logic analyser, power analyser)?

IP and handoff:

• Does the contract specify you own all IP on payment?

• Is source code delivered to a repository you control?

• Is a firmware architecture document included in the deliverables?

Communication:

• Do they ask technical questions before quoting?

• Do they provide written status updates at a defined cadence?

• Do they flag risks proactively rather than at check-in meetings?

Frequently Asked Questions

What should a custom firmware development company deliver at the end of a project?

At minimum: full source code in a version-controlled repository you own, build instructions that allow compilation without vendor involvement, a firmware architecture document covering task structure and peripheral ownership, OTA update procedure documentation, and a list of known limitations and open issues. Any pre-compiled binaries or third-party blobs should be documented with their source, version, and licence. A vendor that delivers a zip file with no documentation and expects you to "just trust the code" has not delivered a professional handoff.

How do you evaluate a firmware vendor's BLE expertise?

Ask them to describe a specific BLE bug they found and fixed in a production device. The answer should name the failure mode (dropped connection, pairing failure, throughput degradation), the diagnostic method (JTAG, Bluetooth sniffer, nRF Connect logs), and the root cause. A strong answer for a consumer BLE device might describe an Android OEM compatibility issue with connection parameter negotiation. Vague answers like "shipped many BLE products" indicate experience breadth without depth.

What is the difference between a firmware development company and a general software development company?

A firmware development company specialises in code that runs on microcontrollers and embedded processors. The work involves RTOS task scheduling, interrupt-driven architecture, hardware peripheral management, memory-constrained design, and real-time timing requirements. A general software development company builds applications for servers, browsers, and mobile platforms where the operating system handles memory management, scheduling, and hardware abstraction. The skills overlap at a conceptual level but diverge completely in practice. A software developer who has never debugged a stack overflow on a Cortex-M4 or characterised sleep current with a power analyser is not qualified to ship production firmware.

How much does custom firmware development cost?

Firmware development cost depends on protocol complexity, hardware integration depth, OTA requirements, and certification scope. A straightforward BLE sensor with basic data logging and no OTA might run USD 15,000–30,000 for a complete firmware package from a specialist firm. A connected medical device with OTA with rollback, security requirements, and wireless certification support will run significantly higher. The more important number is the cost of a bad firmware vendor: a failed production deployment, a field recall, or a failed certification can cost 10–20x the original development contract.

What questions should I ask a firmware vendor before signing a contract?

Ask for the RTOS they would use for your project and why. Ask how they handle OTA updates and what the rollback strategy is. Ask what post-code-review testing they run before delivering a build. Ask who owns the IP and how source code is delivered. Ask what standards they have worked under that are relevant to your product category. Ask how they communicate blockers and what their escalation process looks like. Any vendor with genuine experience will answer these questions in specific, concrete terms. Vague answers to specific questions are a reliable signal of inexperience.

How long does custom firmware development take?

For a battery-powered BLE sensor with OTA support, a realistic timeline from hardware handoff to production-ready firmware is 10 to 16 weeks with a specialist team. For a more complex product with dual-protocol wireless, edge AI, or certification requirements, expect 20 to 30 weeks. Timeline risk comes from three main sources: hardware revisions that require firmware changes, late discovery of a wireless protocol issue requiring architectural changes, and OTA or certification testing that reveals problems needing rework. A vendor that quotes 6 weeks for complex firmware without asking detailed questions is either underscoped or underestimating.

Conclusion

Choosing the right custom firmware development company is an architecture decision as much as a procurement one. The vendor you select determines your codebase quality, your certification readiness, your handoff documentation, and your ability to maintain the product after the engagement ends.

Use the six criteria above to evaluate vendors before you share your hardware or your requirements. Portfolio depth, hardware-firmware integration experience, process maturity, wireless expertise, IP clarity, and communication standards: all six matter, and all six are assessable before you sign.

If you're evaluating firmware development partners for a connected product and want a direct conversation about what the scope actually involves, CoreFragment's embedded engineering team has shipped firmware for healthcare devices, industrial sensors, wearables, and connected consumer products. Share your requirements and you'll get an honest assessment of timeline, risk, and what the right engagement structure looks like.