Data
AI
The Stack Underneath
Hello, we are BRILLIAN’S. Trying to make an effort to put the right people for you to get the best results. Just insight !
You have collected three quotes for firmware design services, and the numbers don't agree on much beyond the invoice format. One agency leads with a slide about "agile firmware sprints." Another shows a portfolio of fitness trackers when your product is an industrial sensor that has to survive a decade on a factory floor. Neither one tells you what happens the day the datasheet turns out to be wrong about a peripheral and someone has to debug that live, on real hardware, before a demo.
That gap, between a services page and what a team actually does when a board misbehaves, is the whole reason this decision is hard. Very few providers will tell you where they'd say no to your project. That's the real test in firmware development, more than any capabilities slide.
This post is built from the questions that actually separate a team that has shipped firmware from one that has only studied it, and from what a design engagement should cost once the padding is stripped out. Read it before your next call so you already know what to ask.
Firmware design is the architectural process of mapping out a device's memory map, structuring the driver stack, deciding between bare-metal execution or a real-time operating system (RTOS), and engineering the long-term update deployment strategy.
While most agency capabilities pages use "design" and "development" interchangeably, they are fundamentally different jobs. Design establishes the rigid structural architecture of an embedded system, while development involves writing the actual code that lives inside those structural boundaries.
Skip the design phase and jump straight to development, and you get firmware that works fine on an engineering bench but falls apart six months later when a feature the architecture never planned for gets bolted on. This architecture phase is the exact layer where embedded firmware development services firms earn their fee—or fail to.
A complete firmware design project typically covers four critical pillars:
Hardware Analysis: Evaluating pin assignments, power budgets, and peripheral constraints.
System Architecture: Mapping out data flows, memory allocation, and concurrency strategies.
Driver & OS Planning: Choosing between a superloop structure or an RTOS like FreeRTOS or Zephyr.
Lifecycle Strategy: Designing a secure, fail-safe Over-the-Air (OTA) update mechanism.
Firmware design rarely covers writing every line of final application code. Some firms scope both together; others hand you a design document and let your own team build from it. Know which one you're buying before you sign anything, because the two get quoted very differently and look nothing alike when compared side-by-side.
Here are nine things you can look for when evaluating firmware design services. Each one is the specific gap that can show up after signing.
A team can be fluent in either STM32 or ESP32. Being fluent in one doesn't automatically make one fluent in another. The two skill sets don't transfer as cleanly. First, evaluate what they have actually shipped to your class of chip. The gap between those two answers shows up fast once real hardware is in the room.
Architecture is the hardest decision to reverse once code sits on top of it. We've shipped firmware on a Cortex-M0 with 16KB of RAM, where every byte had to earn its place. A services provider should be able to walk through that kind of constraint in detail. Ask whether your project needs a from-scratch architecture or fits inside a narrower custom firmware development scope. That call changes the quote, and a real partner can make it in the first conversation.
Board bring-up is where the schematic and the firmware either agree or don't. This is the stage that exposes whether something worked in a demo or actually works. Ask about a bring-up they've done recently. A chip from three years ago doesn't tell you much about today's hardware.
FreeRTOS and Zephyr solve overlapping problems in different ways. Picking between them is an architecture decision, not a preference. A real partner explains the tradeoff for your specific timing constraints. If they can't do that clearly, the rest of the technical calls, including the actual firmware programming choices, were probably made the same way.
Ask specifically about hardware-in-the-loop testing. A vague answer here means the whole testing process is vague, and that gap surfaces after launch, when it's expensive to fix. JTAG and logic analyzers should come up on their own, without you having to ask what tools they use.
Bench-tested firmware and manufacturing-ready firmware are different deliverables. Ask whether this team has taken firmware through an actual production run or only ever handed off a demo. Calibration routines and factory test modes never reach the customer, but skipping them is how unit two hundred stalls the line.
Ask who patches this device in eighteen months, once the original engineers have moved on. Get that answered before you sign. A device shipped without an OTA path built into the architecture usually needs a hardware revision to get one later.
Firmware without documentation becomes unmaintainable the day the person who wrote it leaves. Ask to see a documentation sample before signing. If a provider can't produce one, that tells you what a handoff with them will actually look like.
OTA updates are one of the most common attack surfaces on a connected device. Ask exactly how updates get signed and verified before they run on hardware already in the field. Security built in at the chip, with secure boot and encrypted storage, holds up differently than security added at the API layer after the architecture is locked.
Ask these six directly, in the first call, and listen for an answer that names a real project instead of a general capability.
Not what they've studied. What they've shipped. The answer should include a chip family, a rough unit volume, and ideally an industry, because a team that's only shipped consumer gadgets will make different mistakes on a medical device than a team that's done both.
Every experienced team has a story here, because it happens on nearly every project with real hardware. If they can't produce one, they haven't been through a bring-up that actually tested them.
Push for specifics like unit tests, integration tests, and whether hardware-in-the-loop testing is standard practice or an upsell. A vague answer here is one of the strongest predictors of a rough manufacturing run.
If the answer doesn't mention secure boot or signed firmware images, the update path probably wasn't designed with security in mind from the start, and retrofitting it later usually means a hardware revision.
You're not just buying working firmware. You're buying the ability for someone else to maintain it after the original team moves on. A provider with nothing to show here is telling you what year three looks like.
This is the question most teams forget to ask, and the answer separates a partner from a vendor. A firmware delay usually traces back to a hardware revision nobody budgeted time for, and how a provider handles that, honestly, tells you more than anything on their capabilities page.
Firmware design services costs depend on scope more than anything else, and the honest range is wide enough that a flat number quoted before anyone's seen your schematic is close to meaningless. A design-only engagement on an existing, well-documented board can run $15,000 to $40,000. Add board bring-up from a blank schematic, certification support, or a full connectivity stack, and the same project can climb past $150,000 before manufacturing firmware even enters the conversation.
|
Cost driver |
What pushes it up |
|
Board bring-up |
Starting from a new board with no existing firmware base |
|
Certification |
Medical, automotive, or safety-critical compliance testing |
|
RTOS and connectivity depth |
Full device-to-cloud stacks cost more than a single sensor loop |
|
Hardware revisions |
Each round where board and firmware disagree adds time |
|
Manufacturing firmware |
Calibration and factory test modes add scope late in the project |
None of these move in isolation. A medical device with a new board and a full connectivity stack stacks three of these at once, which is why certified projects routinely run several times the cost of a simple consumer device on a known chip.
A few numbers worth having in your head before a call:
Design-only, existing board, no certification: $15k to $40k
Full build, new board, consumer-grade: $40k to $90k
Certified build (medical, automotive, industrial safety): $90k to $250k or more, driven mostly by compliance testing rather than engineering hours
Manufacturing firmware and factory test modes: usually 10 to 20% on top of the base build
These are ranges, not quotes, and any provider that gives you an exact number before seeing your schematic is guessing. A 30-minute conversation about your specific board gets you a real number faster than any range in a blog, including this one.
The eight criteria above and the six questions aren't a scorecard where more checkmarks wins. A provider who's honest about which of these they're weak on is more trustworthy than one who claims strength on all eight in the first call.
If your project sits on an established board with no certification and a short field life, price is a fair way to choose. If it doesn't, price is the least useful signal you have, and the questions matter more than the quote.
Send the schematic to two providers, ask the six questions above, and pay attention to which one names a real project instead of a general capability. That answer will tell you more about the next eighteen months than any proposal will.
Cost depends mostly on scope, with board bring-up, certification, and connectivity depth as the biggest swing factors. A design-only engagement on an existing, documented board can run $15,000 to $40,000. A certified medical or automotive build can climb past $150,000, since compliance testing alone often costs more than the engineering.
Firmware design covers the decisions, the memory map, the architecture, the driver structure, and the update strategy. Firmware development is the actual coding that happens inside those decisions. Some providers scope both together, and others hand off a design document for your team to build from.
A design phase on a known board usually runs a few weeks. A new board with certification requirements can take several months, mostly because of hardware revisions rather than the design work itself. Each round where the board and the firmware disagree adds time to the schedule.
Ask what they've actually shipped on your class of chip, how they handle a schematic that doesn't match the firmware, and how they sign and verify OTA updates. Ask to see a documentation sample too. The answers to these tell you more than a proposal will.
A vendor SDK works fine for a simple, short-lived product on a well-supported chip. Custom design earns its cost when your product has a long field life, a differentiating feature, or power and timing constraints a generic SDK wasn't built to handle. Two or more of those conditions usually settles the decision.
You might also like
