Firmware Development Services: What Hardware Startups Actually Need to Buy in 2026

What firmware development services actually cover

When a vendor says firmware, they may mean any subset of ten distinct deliverables, and the subset is where quotes diverge. In rough order of how a project runs: board bring-up (clocks, power, a console, first signs of life); the board support package (BSP) and bootloader; device drivers for each sensor and peripheral; either bare metal code or RTOS integration with FreeRTOS, Zephyr or embedded Linux built through Yocto; the connectivity stack, whether that is Bluetooth Low Energy, Wi-Fi, Thread, Matter, LoRaWAN or cellular over LTE-M and NB-IoT, usually speaking MQTT over TLS; an OTA update pipeline with A/B partitions and rollback, signed against secure boot using firmware signing; device identity and secure provisioning, often with mTLS credentials injected on the line; production test firmware and a hardware-in-the-loop (HIL) test rig; and the documentation a certification body will ask for, now including an SBOM.

One distinction worth settling, because buyers ask: firmware is the software that runs on the MCU or SoC itself; embedded software is the broader term that also covers application code on a Linux-class device. Vendors use them interchangeably. What matters is which of the ten items above is in your statement of work.

The four ways to buy, and what each one really costs

The figures above are market anchors, not quotes: US$167,438 is ZipRecruiter's US average for a firmware engineer as of August 2026, and US$114 an hour is the average freelance firmware engineer rate reported by contractrates.fyi in February 2026 from a small self-reported panel. For context on the employment side, the US Bureau of Labor Statistics puts the median wage for electronics engineers at US$130,220 a year, with the top decile above US$206,960.

What the table cannot show is that the four models fail differently, and choosing badly is expensive in a way that does not appear in any rate card. That is the next section.

When each model breaks

The in-house hire breaks on departure. One firmware engineer is a bus factor of one: the board files, the toolchain quirks and the reason that timer is configured that way all live in one head. The Institute for Printed Circuits puts the median cost of employee turnover at 21% of annual salary, and for a sole firmware owner the real cost is the standstill, not the recruiting fee. A hire is the right answer when firmware is the product and the roadmap is years long, not months.

The product studio breaks on scope change. Fixed-scope contracts price certainty, and hardware projects rarely deliver it: a silicon shortage, a failed radio test or a mechanical change rewrites the firmware plan. Empirical work on outsourced software contracts finds that contract type is itself a predictor of outcomes: Gopal and colleagues, studying offshore projects in Management Science, showed that fixed-price and time-and-materials arrangements produce systematically different vendor behaviour and profitability (reference). The lesson for a buyer is not that one is better, but that a fixed price on an unstable scope buys a negotiation, not certainty.

The fractional consultant breaks on growth. One excellent senior engineer is the fastest possible start and the hardest thing to scale. Adding people late does not fix it either: that is Brooks's Law, from The Mythical Man-Month: adding manpower to a late software project makes it later, because ramp-up and communication cost more than the added capacity delivers. And the handover is a real cost, not a formality: research on distributed development identifies knowledge transfer and social ties as a primary determinant of whether collaboration succeeds (Kotlarsky and Oshri, EJIS, reference).

The embedded nearshore team breaks without a counterpart. If nobody on your side reviews architecture decisions, an outside team will make them alone and you will inherit choices you cannot explain to a certification body.

And the case nobody plans for: inheriting firmware someone else wrote. ByteNana itself started in 2022 with exactly this kind of job: a project whose previous team had vanished. GenoStories is a later example: it arrived with critical bugs blocking store publication; an audit found architectural flaws across the app and its back end, and we stabilised it and shipped it to the App Store and Google Play.

What it costs, and what moves the number

Hourly rates are the least useful number in this market, because the hours differ. A team that has done board bring-up thirty times bills fewer of them than one learning on your board, which is why effective project cost (rate multiplied by hours actually needed) is the only fair comparison. Software cost estimation has understood this since Boehm's Software Engineering Economics (reference): effort scales with size and a set of cost drivers, and team capability is one of the largest drivers in the model.

What actually moves a firmware quote:

• Silicon maturity. A vendor reference design for your SoC can halve bring-up. A custom board on new silicon does the opposite.
• Radio count and certification scope. Each radio adds test time and fees. Bluetooth SIG qualification alone is US$12,000 per product for non-members under the fee schedule effective March 2026.
• Safety or medical class. IEC 62443 or ISO 13485 work changes the documentation burden more than the code.
• Greenfield versus reuse. Inherited code with no tests is usually slower than starting clean, and an honest vendor says so during scoping.
• Who writes the test plan. If it is not in the statement of work, it is not in the price, and you will pay for it later in field returns.

ESP32 board derived from the Espressif reference design (WiseTec sensor for Multotec): about 40 hours. A custom board on new silicon with no reference design: about 150 hours.

Running cost is the line most budgets miss. An OTA update pipeline has a build cost and a subscription: device management runs from US$34 a month on Mender for a small fleet to US$3,495 a month on Memfault at the Growth tier, with Golioth charging US$0.25 per connection per month and AWS IoT Device Management billing per device and per tunnel.

Twelve questions that separate a firmware partner from a body shop

Ask all twelve. The answers, not the portfolio, tell you what you are buying.

1. Who owns the repository during the project, and where does it live?
2. Who holds the firmware signing keys, and what happens to them at handover?
3. Is there continuous integration on hardware, or do builds only run on a laptop?
4. Do you have a hardware-in-the-loop (HIL) test rig, and will we get it?
5. Who writes the test plan, and is it in the statement of work?
6. Which RTOS would you choose for this product, and what would change your mind?
7. How do you handle secure boot and rollback: show me a release you shipped with A/B partitions.
8. What is your notice period, and how does ramp-down work mid-project?
9. Does the contract assign IP assignment of everything, including build scripts and test fixtures?
10. Who talks to the certification lab, and have you done FCC Part 15 or CE/RED before?
11. What documentation do we get at the end, and will it include an SBOM?
12. What is your time to first commit after signature?

Clients almost always ask about rates, NDAs and time zones. Almost none ask who holds the signing keys or what happens to OTA updates if the relationship ends, the two questions that matter most.

What the EU Cyber Resilience Act changed about buying firmware

If your device will be sold in the European Union, firmware is now a regulated deliverable. The EU Cyber Resilience Act entered into force in December 2024; its reporting obligations (notifying actively exploited vulnerabilities) have applied since 11 September 2026, and the main obligations apply from 11 December 2027. Nothing on page one of the search results for firmware services mentions this.

For a buyer, three procurement consequences follow. First, someone must own vulnerability monitoring and disclosure for the life of the product, which means the OTA update pipeline is no longer optional: a device you cannot update is a device you cannot remediate. Second, an SBOM becomes a deliverable rather than a nicety, and it has to be produced by the build system rather than assembled by hand afterwards. Third, the contract has to say who does this work after launch, because the obligation does not end at shipping.

The standards world has been here longer than the regulators. The IETF's SUIT working group published a firmware update architecture for IoT as RFC 9019 and a manifest information model as RFC 9124, both of which define the threat model a serious update system should meet. On the research side, the compromise-resilient design that most modern update systems borrow from is The Update Framework, published at ACM CCS in 2010 (reference) and adapted for vehicle ECUs as Uptane. For platform-level protection, NIST's SP 800-193 sets out firmware resiliency guidelines: protection, detection and recovery (reference).

A vendor who can name RFC 9019 and explain their signing roles is telling you something a portfolio cannot.

How long each model takes to produce working firmware

The slowest path to working firmware is almost always hiring, because the clock starts before anyone writes code. Ashby's 2026 analysis of startup hiring, covering more than 1,200 startups and 32,000 hires, found technical roles at companies under 25 people took 42 days to hire with a recruiter and 62 days without, and that is for technical roles generally, not for a specialism as thin as firmware.

Our figures come from recent projects, including the WiseTec sensor system for Multotec: ESP32 silicon, C++ on FreeRTOS, a vendor reference design available, and engineers who had shipped on ESP32 before.

How to run the first 30 days so the engagement does not fail

Most failed firmware engagements fail in week one, and not on skill. They fail because the board is on someone's desk in another city, the schematics are a PDF from three revisions ago, and nobody has written down what "done" means.

A first 30 days that works:

• Days 1-2: access. Repository, CI, issue tracker, the current schematic revision, the BSP if one exists, and hardware in the engineer's hands: two boards, not one, because a bricked board should not stop the week.
• Days 3-5: a small real task. Not a sample project: something in the actual codebase that ends in a merged pull request. This is the fastest honest signal about both the engineer and your codebase.
• Week 2: a written definition of done. What tests must pass, what the HIL test rig covers, what gets documented, what "working" means for the first milestone.
• Weeks 3-4: a demo on real hardware. Fortnightly, on the device, with the team watching. Slides are not a demo.
• Throughout: one named counterpart on your side. Research on distributed development is consistent that cross-site work takes longer than colocated work when coordination is left informal: Herbsleb and Mockus measured this in IEEE Transactions on Software Engineering (reference), and the cheapest correction is a single person who answers questions rather than a queue.

Week one: repo and tool access, building the existing firmware on our own bench, flashing a board, and sending a written list of open questions by Friday. What most often goes wrong: hardware arrives late: we ask for two boards shipped before day one.

Frequently asked questions

What is the difference between firmware and embedded software?

Firmware is the code that runs directly on an MCU or SoC, from the bootloader up through device drivers and the application. Embedded software is the wider term and includes application code on Linux-class devices built with Yocto. Vendors use both words for the same work; what matters is the deliverable list in the statement of work.

How much does firmware development cost?

It depends on scope, not on hourly rate. A US firmware engineer averages US$167,438 a year and US freelance consultants average around US$114 an hour, but project cost is driven by silicon maturity, how many radios need certification, and safety class. Bluetooth SIG qualification alone is US$12,000 per product for non-members in 2026.

Do I need an RTOS, or is bare metal enough?

Bare metal is sufficient for a single-purpose device with a handful of tasks and no network stack. Once you add Bluetooth Low Energy or Wi-Fi, an OTA update pipeline and concurrent sensing, an RTOS such as FreeRTOS or Zephyr stops being overhead and starts saving time. Real-time scheduling theory has formalised this trade since Liu and Layland's 1973 paper in the Journal of the ACM (reference).

Who owns the code if we hire an outside firmware team?

Whatever the contract says, which is why IP assignment should cover source, build scripts, test fixtures and the HIL test rig, not just the shipped image. Ask where the repository lives during the project and who holds the firmware signing keys afterwards.

Can a vendor take over firmware someone else wrote?

Yes, and it should start with a paid audit rather than a fixed-price rewrite quote: inherited code without tests is usually slower to extend than new code. An audit takes one to two weeks and usually finds no secure boot, credentials hard-coded in the image, and no way to roll back a failed update.

The short version

• There are four ways to buy firmware, and they differ more in time to working software than in hourly rate.
• A single in-house firmware engineer is the highest-risk option for a small team, because the bus factor is one.
• Certification and the OTA update pipeline are budget lines, not details, and since September 2026 the EU Cyber Resilience Act makes the update path a legal requirement for anything sold in the EU.
• Ask the twelve questions. The answers about repository ownership, firmware signing keys and ramp-down tell you more than any portfolio.