Last updated July 2, 2026
What Firmware Development Actually Takes to Build, Test, and Ship
8 mins read
Summarize with AI:
The board boots. The sensors read correctly on the bench. The enclosure is already signed off, and the launch date is on the calendar. Nobody has started firmware development yet, and nobody in the room can say when they will.
This happens on more hardware projects than teams admit. Firmware gets treated as the thing that happens after the important decisions are made, when it should be shaping those decisions from the first schematic review. A sensor picked without checking driver support. A wireless chip chosen before anyone confirmed the protocol stack was mature. A battery budget set before anyone modeled what the radio actually draws mid-transmission. All fixable. All expensive to fix late.
This guide is for the people sitting in that room: product teams, engineering managers, CTOs, and founders trying to understand what firmware development actually involves before they commit a timeline to it. By the end, you'll know what firmware is and does, how the work moves stage by stage, what it costs to get wrong, and what to check before you hand it to anyone — an in-house hire, a contractor, or a firmware development company.
Firmware isn't an app. You can't download it from a store, and there's no OTA-eligible update sitting in a queue every time you open it, because most firmware doesn't have anything to open. It runs the moment the device powers on, whether or not anyone is watching.
Hardware is the physical device — the board, the chip, the sensors soldered onto it. Software, in the way most people use the word, runs on top of an operating system: a phone app, a web dashboard, anything with a UI you tap or click. Firmware sits between the two. It talks directly to the processor, manages memory that's measured in kilobytes rather than gigabytes, and has no OS underneath to catch its mistakes.
That last part is what trips up software-first teams. A bug in a web app costs you a deploy. A bug in firmware already sitting in ten thousand shipped units costs you a recall, or a field update that never reaches every device in the field.
Firmware is the reason a device behaves like a device instead of an inert circuit board. It's what's running when:
Sensors - decide whether a reading is even valid before anything downstream uses it
Motors - convert a command into the right voltage and timing, not just an on/off signal
Displays - redraw only the part of the screen that changed, not the whole frame
Power management - decides when to sleep, when to wake, and what that costs the battery
Connectivity - holds a Bluetooth or Wi-Fi connection without dropping it mid-transfer
Safety features - fire correctly even if everything else on the board has already failed
Every one of those is firmware's job. None of it is optional, and none of it is visible to the end user until it breaks.
Ask that question across five industries and the specifics change every time. The underlying pattern doesn't. Firmware is used wherever a physical product has to make decisions on its own, in real time, with no one supervising it.
Consumer electronics. The logic inside a smart speaker, a fitness tracker, or a robot vacuum, deciding what to do with sensor input the instant it arrives, on hardware where a few extra cents per unit at scale is the difference between a viable margin and a rejected BOM.
Industrial automation. PLCs, motor controllers, and factory-floor sensors built to run for years without a reboot, often in facilities where pushing a Wi-Fi update isn't an option and never will be.
Medical devices. Firmware here carries more weight than almost anywhere else. A dosage pump or a diagnostic device runs firmware that's regulated, documented, and tested to a standard most consumer products never come near.
Automotive. A modern vehicle runs dozens of separate firmware systems. The infotainment unit gets the attention, but it's the ones nobody thinks about, like the systems controlling braking response, that actually can't fail.
IoT and smart home. The connectivity layer carries the load here, firmware that has to talk to a hub, a phone app, and often a cloud service, all while running on a chip with a fraction of a smartphone's power budget.
Wearables. The tightest power and size constraints in this list. Every function competes for the same shrinking battery, which is why wearable firmware is usually the most optimized code on the entire product.
Different industries, different constraints. Same underlying question in every one of them: what does this chip need to get right, every time, with nobody watching.
At a high level, firmware development moves through a fixed sequence. Skip a stage or rush it and the cost doesn't disappear, it just shows up later, usually in a manufacturing run, which is a far more expensive place to find a bug than a lab bench.
What does the device need to do, and what does the hardware allow it to do. Battery life targets, real-time response requirements, and certification needs all get defined here, before anyone writes a line of code. Skip this and you find out the hard way, mid-project, that the battery target and the wireless protocol you picked were never compatible in the first place.
Reading the schematics. Understanding the chip's datasheet. Knowing exactly what peripherals are on the board and how they're wired. Firmware written without this step tends to work on the bench and fail in production, because someone assumed the board supported something it didn't. That assumption is usually invisible until a hundred units are already assembled.
Deciding on structure before writing code. Bare metal or RTOS. How the driver layer talks to the application layer. How updates get delivered once the device is already in someone's hands. This decision is expensive to reverse once code exists on top of it, so it gets made carefully, not quickly. Teams that skip straight to coding usually end up rewriting the same driver layer twice, once for the prototype and once for the version that actually scales.
The actual coding stage, drivers, middleware, and application logic, written against whatever architecture the previous stage locked in. Code written before the architecture is settled tends to encode that instability permanently, which is how a "quick prototype hack" ends up shipping in the production build.
Unit tests, integration tests, and hardware-in-the-loop testing, where the firmware runs on real hardware under real conditions instead of a simulator. Most of the bugs that would otherwise reach a customer get caught here, assuming testing wasn't the first budget line cut when the schedule got tight. It usually is, and it's usually the decision teams regret first.
Flashing firmware onto boards at scale, handling calibration, and catching the version of a bug that only shows up when a thousand units are on the line instead of one prototype on a bench. A bug that never appeared once in a hundred bench tests can still show up on unit 200 of a production run, because manufacturing variance exposes edge cases a lab bench never will.
Firmware development moves through six structured stages, from defining what the device needs to do all the way through what happens after it ships.
Requirements Analysis: Engineers define what the device needs to do before any code exists, working within real hardware limits like memory, processing power, and battery draw.
Architecture & Design: The blueprint gets built here. Memory layout, hardware interfaces, and communication protocols like I2C, SPI, or UART all get decided at this stage, not discovered later.
Implementation (Coding): The firmware gets written, usually in C or C++ for direct hardware control, including drivers and an RTOS if the device needs to handle more than one task at once.
Testing & Debugging: Unit tests check individual functions. Integration tests check whether subsystems actually talk to each other correctly. Debugging tools like oscilloscopes and logic analyzers catch the faults that only show up at the hardware level.
Hardware Integration: Firmware gets flashed onto the real device for the first time. This is where teams fine-tune behavior against actual hardware instead of a simulator, and where problems invisible on a dev board finally surface.
Deployment & Maintenance: The product ships, but the work doesn't stop. OTA updates, security patches, and feature additions keep going for as long as the device stays in the field.
Six stages, and skipping straight from requirements to coding is the shortcut that costs teams the most time later, usually in stage four, when the gaps that Architecture & Design was supposed to catch finally show up.
Not every firmware project is the same shape. The three categories below cover most of what teams actually run into, and picking the right one early saves a rewrite later.
Embedded firmware development is firmware written specifically for embedded systems, devices with tight constraints on memory, power, and processing, usually with no general-purpose operating system underneath to absorb mistakes. This is the deepest end of the pool. Real-time requirements, direct register access, and a hardware budget that leaves no room for the inefficiencies a full software stack could normally hide.
Most of what falls under this category shows up in products where failure isn't an inconvenience, it's a safety issue: industrial controllers, medical devices, automotive systems. The firmware has to behave identically every single time, on hardware that might run unattended for years between service visits.
Teams building their first embedded product often underestimate how different this is from writing software with an OS underneath. There's no garbage collector cleaning up a memory leak. There's no crash log emailing itself to a dashboard. Whatever the firmware does wrong, it does wrong silently, in the field, until someone notices the device stopped responding.
Custom firmware development means building firmware purpose-fit to a specific product, rather than adapting an off-the-shelf firmware package or a vendor's reference SDK. It costs more upfront than the shortcut version, and it pays that cost back in control. No vendor lock-in, no waiting on someone else's release schedule to fix a bug that's blocking your launch.
The tradeoff shows up early, usually at the scoping stage. A vendor SDK gets a product to a working prototype fast, but it also ties every future decision to whatever that vendor decided to support. Custom firmware takes longer to get to the same prototype, but nothing about the product's roadmap is hostage to a third party's priorities six months later.
This is usually the right call for products with a long field life or a differentiated feature set, where the thing that makes the product worth buying is exactly the thing a generic SDK wasn't built to support.
Manufacturing firmware development is built around the realities of a production line, not just the finished product. Calibration routines, factory test modes, and provisioning steps that never ship to the end customer but decide whether a production run goes smoothly or stalls on unit two hundred.
This category gets skipped in planning more often than any other, because it's invisible in a demo. A prototype doesn't need a factory test mode. A production run of ten thousand units absolutely does, or every unit gets hand-tested by an engineer who has better things to do.
Getting this right early, before the first production run rather than after a stalled one, is usually the difference between a manufacturing partner who trusts the next order and one who starts asking harder questions about the timeline.
Firmware development services cover the parts of this work most product teams don't build entirely in-house, and the scope goes wider than most people expect going in. What typically gets scoped to a specialized partner:
Microarchitecture selection: Choosing the right processor architecture for the product's power, cost, and performance targets before anything gets committed to silicon.
Board support packages: Building the layer that lets an operating system or application code actually run on a specific board, instead of starting driver development from zero every time hardware changes.
Edge AI development: Getting inference models running directly on-device, within the power and memory limits embedded hardware actually has, rather than assuming a cloud connection will always be there to do the heavy lifting.
Fleet device management and OTA: Once a product ships in volume, someone has to track device health, push updates safely, and roll back a bad release before it bricks a fleet instead of one unit.
Silicon-to-cloud security: Security that starts at the chip, not the API layer, covering secure boot, encrypted storage, and everything in between before data ever reaches a server.
A team building its first connected product rarely needs all five from day one. A team on its third or fourth product usually needs the ones that keep eating their internal engineers' time long after launch, and that's almost always fleet management and security, since neither one stops being work once the device ships.
The right technology stack for a firmware project depends almost entirely on the chip, the power budget, and how much of the connectivity layer the product actually needs. There's no universal answer here, but there is a common set of tools most projects choose from.
|
Category |
Common choices |
Used for |
|
Languages |
C, C++, Rust (growing adoption) |
Core firmware logic and low-level driver code |
|
RTOS |
FreeRTOS, Zephyr, ThreadX |
Task scheduling on memory- and power-constrained hardware |
|
Debugging |
JTAG, SWD, logic analyzers |
Hardware-level debugging and board bring-up |
|
Connectivity protocols |
BLE, Wi-Fi, Zigbee, LoRaWAN, MQTT |
Device-to-device and device-to-cloud communication |
|
Build tooling |
CMake, Make, vendor SDKs (STM32Cube, ESP-IDF) |
Compiling and flashing firmware onto target hardware |
|
OTA frameworks |
Mender, AWS IoT Device Management, custom bootloaders |
Delivering firmware updates after a device ships |
A battery-powered sensor with a two-year deployment window and a mains-powered industrial controller will make almost none of the same choices from this table, and that's normal. The technology serves the constraint, not the other way around.
Picking a firmware development company comes down to a short list of real questions, not a capabilities page full of buzzwords. Here's what actually separates a partner who's shipped firmware from one who's just studied it.
A team that's worked with STM32 boards isn't automatically the right fit for an ESP32-based product. Ask what they've actually shipped, not what they've read the datasheet for. The gap between those two answers shows up fast once real hardware is in the room.
FreeRTOS and Zephyr aren't interchangeable skill sets, and BLE solves a different problem than LoRaWAN. A real partner explains the tradeoff for your specific constraints instead of listing every option on a capabilities slide. If the answer to "why this RTOS for our product" is vague, the rest of the engineering decisions probably were too.
Has this team taken firmware from a prototype through an actual production run, or only ever handed off a working demo. Bench-tested firmware and manufacturing-ready firmware are not the same deliverable, and the difference only shows up once a few hundred units are on a line.
Ask specifically about hardware-in-the-loop testing. A vague answer here usually means the testing process is vague too, and that gap tends to surface exactly when a product can least afford it, after launch.
Who patches this device in eighteen months, after the original engineers have moved to other projects. Get that answered before signing, not after the first security issue. Ask to see a documentation sample too. Firmware without documentation becomes unmaintainable the day the person who wrote it leaves.
OTA update mechanisms are a common attack surface. Ask exactly how updates get signed and verified before they're allowed to run on a device already in the field.
None of this is a one-time conversation either. Anyone who's sat through the process of vetting a CTO-level outsourcing decision already knows most of these questions, just aimed at a more specialized skill set than the usual software hire.
Firmware isn't the part of a product you bolt on after the important decisions are made. Every team that treats it that way ends up paying for it in a manufacturing run, a stalled production line, or a support queue full of devices nobody can update. The teams that get this right treat firmware as part of the product decision from the first hardware spec review, not the week before launch.
If you're sitting on a hardware timeline with no firmware plan yet, the one thing worth doing before your next hardware review is getting someone who's actually shipped firmware engineering services into the room, even for an hour. Catching an architecture mistake at that stage costs an hour of someone's time. Catching it after ten thousand units are already on a shelf costs a recall.
Most firmware projects run anywhere from a few weeks for a simple, single-purpose device to over a year for something with certification requirements or complex connectivity. The biggest swing factor isn't the coding itself, it's how many rounds of hardware revision the project needs before the board and the firmware actually agree with each other.
C and C++ handle the vast majority of firmware, mainly because they give direct control over memory and hardware with almost no runtime overhead. Rust is gaining ground for new projects where memory safety matters more than the ecosystem maturity C still has a lead on.
Yes, through OTA infrastructure, but only if that capability gets designed in from the start. A device shipped without an update path baked into the architecture usually can't have one bolted on later without a hardware revision, which is why OTA planning belongs in the architecture stage, not the launch checklist.
Embedded firmware development is firmware written for devices with tight memory, power, and processing constraints, usually with no general-purpose operating system underneath to absorb mistakes. It's the deepest end of firmware work, real-time requirements and direct register access, with none of the safety nets a full software stack normally provides.
Cost depends heavily on scope, whether the project needs board bring-up from scratch, certification support, or just driver development on an existing design. A simple consumer device with no certification needs can run a fraction of what a certified medical or automotive project costs, since compliance testing alone can rival the engineering cost.
You might also like
Hello, we are BRILLIAN’S. Trying to make an effort to put the right people for you to get the best results. Just insight !
503, Fortune Business Hub, Science City Road, Sola, Ahmedabad, Gujarat, India Pincode- 380060
+ 91 9313644148
sales@brilworks.com
