Key Takeaway
- Firmware work is judged on two things that supplier pages rarely mention: how a device recovers from a bad image, and what you actually receive at the end.
- Bare metal or an RTOS is the first real decision. It follows from timing and from how many things the device has to do at once, not from preference.
- Ask for the deliverables list in writing: source, build scripts, toolchain versions, test reports, and who owns the intellectual property.
- If the product carries a safety or security obligation, name the standard before the quote. MISRA C, IEC 62304 and IEC 62443 all change the estimate.
- The update path is the part that turns a shipped product into a supportable one. Plan the bootloader before the application.
Overview
01
What firmware development services cover
Firmware is the software that makes a piece of hardware behave. It boots the board, drives the peripherals, holds the logic, and keeps running without anyone watching.
Most firmware development services pages list the same capabilities. Bring-up, drivers, RTOS work, connectivity, low power, test. The list is accurate and it does not separate one supplier from another.
The naming varies more than the work does. Firmware services, firmware engineering services and firmware design services describe the same discipline, and so does a firmware programming service. Custom firmware development services usually means firmware written for your own board rather than for a vendor reference design.
What separates them is narrower. Whether they plan the update path before the application, whether they hand over a build anyone else can reproduce, and whether they have taken a product through the standard your market requires.
This page covers those decisions. For the wider view across embedded development services, see our guide to choosing an embedded software development company.
Scope
02
The six pieces of a firmware engagement
A quote that covers only the application layer is a quote for part of the job.
Board bring-up
Power rails, clocks, memory and the first serial output. This is where a new board either works or reveals a hardware fault, and it is the stage most likely to run over.
Drivers and the hardware layer
Sensors, radios, displays and storage, wrapped so the application does not care which chip is underneath. A clean hardware layer is what lets you change a component later without rewriting the product.
Bare metal or an RTOS
A single control loop is simpler to reason about and cheaper to certify. An RTOS earns its place once the device has to hold several deadlines at once, and the choice should follow the timing, not the habit.
Bootloader and update
How a device takes a new image, and how it gets back if that image is broken. Plan this first, because retrofitting a recovery path onto shipped hardware is the most expensive fix in firmware.
Secure boot and keys
Signed images, a root of trust in silicon, and a documented answer to where the signing keys live. For anything sold into regulated markets this becomes a procurement question rather than an engineering one.
Test and evidence
Unit tests on the host, hardware tests on a rig, and a record of what was run against which build. Firmware testing services are worth buying separately when the rig does not exist yet, because firmware without a rig gets tested by customers instead.
Deliverables
03
What you should receive at the end
This is the clause buyers skip and later regret. Ask for it in writing before the work starts.
| Deliverable | Why it matters |
|---|---|
| Source, with history | A zip of final files is not a codebase. You want the repository and the commits behind it |
| Build scripts and pinned toolchain versions | Firmware that only builds on one laptop is firmware you cannot maintain |
| Board files and pin mapping documentation | The next engineer needs to know which pin does what without reading every driver |
| Test reports tied to build numbers | Evidence that a given image passed a given set of checks, which is what an auditor asks for |
| Signing keys and the process around them | If the supplier holds the only keys, you cannot ship an update without them |
| A written statement of who owns the intellectual property | Ownership of the firmware, of any middleware written for you, and of the licences underneath |
Most disputes at the end of a firmware project are about one of these six lines. None of them costs anything to agree at the start.
Standards
04
Standards that change the estimate
Firmware quotes vary widely for the same brief. Usually the reason is that one supplier priced a safety route and another did not.
MISRA C, published by the Motor Industry Software Reliability Association and currently at the 2012 edition, is a set of guidelines that removes undefined and error-prone constructs from C. Writing to it and proving compliance with a static analyser is real work that has to be in the estimate.
Above it sit the sector standards. IEC 61508 for industrial functional safety, ISO 26262 for automotive, IEC 62304 for medical device software, DO-178C for airborne software. Each brings documentation, traceability and tool qualification.
Security has its own track. IEC 62443 covers cybersecurity for industrial automation and control systems and defines a secure development lifecycle, which matters for anything going into a plant.
Name the standard in the first conversation. A quote built without it can be out by a wide margin, and the gap appears at the audit rather than at the kick-off.
Engagement
05
How to start without betting the product
Five steps that surface the real risks early.
- Start with bring-up on one board. Fixed price, fixed date. It tells you more about a supplier than any proposal, because bring-up is where hidden hardware problems appear.
- Settle hardware access. Boards at your site with remote debugging, boards at theirs, or a split. Decide it before the schedule is agreed.
- Design the update path next. Bootloader, image format, recovery from a failed update, and how a device in the field is reached.
- Build the test rig alongside the firmware. Not after. A rig built later tests only what already works.
- Agree the deliverables list. The six lines in the table above, written into the contract rather than into an email.
If the work is mostly verification rather than new features, our guide to offshore test automation covers what to hand over and what to keep.
Working With Us
06
How Dev Station runs firmware work
We build firmware as a standing team rather than a rented pair of hands, and we take on bring-up, the hardware layer, the update path and the test rig alongside the application.
Where a customer already has an electronics house, we work to their schematics instead of pretending hardware is a software problem. Where a product needs a certification route, we agree the coding standard and the evidence trail before the first sprint.
Our engineers work from Vietnam with overlap into UK GMT and US Eastern and Pacific hours, and we invoice in GBP or USD. For the supplier checks that come before any of this, see how to choose a software development company in Vietnam. Send us your schematic and your target standard and we will tell you what we would build first.
FAQ
07
Frequently asked questions
What buyers ask when scoping firmware work.
What is included in firmware development services?
Board bring-up, device drivers and a hardware abstraction layer, the application logic, the bootloader and update path, secure boot where the product needs it, and the test setup that proves the image works on real hardware.
What is the difference between firmware and embedded software?
In practice the words overlap and most suppliers use them for the same work. Firmware usually implies the layer closest to the silicon, while embedded software is used more broadly for anything running on the device, including an application on top of embedded Linux.
Should we use bare metal or an RTOS?
Bare metal suits a device doing one thing on a predictable loop, and it is simpler to reason about and cheaper to certify. An RTOS earns its cost once several deadlines have to be held at the same time. Let the timing requirements decide.
How much do firmware development services cost?
Buyers looking for cost effective solutions rarely find a published figure, because no supplier publishes one, because the range is enormous and depends on the standard, the silicon and the state of the hardware. Compare a fixed price for bring-up on one board, then a fixed price for the update path, rather than comparing hourly rates.
Who owns the firmware at the end?
Whatever the contract says, which is why it needs to say something. Put ownership of the source, the board documentation and the signing keys in writing on day one.
Want an AI assistant to summarize or cite this guide?
Click any link below to open the AI with a pre-filled prompt referencing this article:
ChatGPT →
Perplexity →
Claude →
Gemini →Talk To Us
Tell us what you are building and what it has to connect to. An engineer answers, and you get a straight view of what the work would take.
Get In Touch →
