The board is the part everyone talks about. Then it arrives in a padded envelope, you plug it in, and nothing happens, because there is still no firmware for your custom PCB. Something has to run on that chip before the thing you designed does anything at all.
This is the half of the project most first-time hardware founders do not budget for, in money or in weeks. The good news is that the options are few and the tradeoffs between them are clear. Here they are, with real 2026 numbers.
The short version
There are four realistic ways to get firmware onto a custom board: write it yourself against the chip maker toolchain, hire an embedded contractor, prove the idea on a dev board and port the code over, or have your design tool write it. Contracting it out is the fastest path to someone else owning the problem and costs roughly $2,000 to $12,000 for a typical first product, or $67 to $171 an hour for a US freelancer. Writing it yourself costs nothing but your time, and the time is the part people underestimate. Porting from a dev board is the cheapest real shortcut. Letting the design tool write it is new, promising, and limited to the chips it supports.
What firmware actually has to do on a first board
It helps to be specific about the job, because "write the firmware" sounds like one task and is really four.
Bring the chip up: get power and clocking right so the processor boots and you can talk to it. Prove the wiring: confirm that the sensor or display on the other end of your traces actually answers. Read it properly: turn whatever the part returns into real numbers in the right units, at the right rate. Report it: push that out to an LED, a screen, a radio or a log so a human can see it.
On a dev board, steps one and two are done for you. On your own board, they are yours.
Why bring-up is where first boards die
Ask people who have shipped hardware where their first board stalled and very few will say the schematic. They will say bring-up, the stretch between the parcel arriving and the first believable reading.
The reason is diagnostic, not technical. When nothing happens, you cannot tell whether the code is wrong, the pin assignment is wrong, the part is on backwards, or the part is dead. Each of those has a different fix and they all look identical from the outside: a quiet board. So you end up debugging two systems at once, with no known-good reference, which is exactly the situation software people are trained to avoid.
Everything that reduces that ambiguity is worth more than it looks. A pin map you trust. A part you have read the datasheet for. A written record of what each connector and test point is supposed to do before you power anything on. We wrote a whole post on what to check when your board arrives, before you plug it in, because the half hour spent there routinely saves a week.
A bring-up guide like this one is not firmware. It is the reference firmware work starts from: what each pin is, what voltage goes where, what should light up first.
The four paths
1. Write it yourself with the chip maker toolchain
Every major microcontroller family ships a free SDK. Espressif publishes ESP-IDF for the ESP32 family, Raspberry Pi publishes a C and a MicroPython SDK for the Pico, Nordic and ST publish their own. These are real, well-documented, and free.
The cost is setup and learning. The ESP-IDF getting started guide walks you through installing a cross-compiler toolchain, CMake, Ninja and the framework itself before you build a single line of your own code. None of that is hard if you have done it before. If you have not, it is a day you did not plan for, and it comes before you learn anything about your actual product.
Pick this if: you can already program, your device is simple, and you would rather own the code than own a contract. Avoid it if: the schedule matters more than the learning does.
2. Hire an embedded contractor
The straightforward option, and the one with the widest price range. Freelance marketplace data for 2026 puts US embedded engineers at roughly $67 to $104 an hour junior, $85 to $135 mid-level and $110 to $171 senior, with non-US rates well below that, according to SecondTalent cost-to-hire data. For context on what that reflects, ZipRecruiter currently reports an average of $58.66 an hour for salaried embedded firmware engineers in the US.
Fixed-price project quotes tell a similar story from the other direction. One 2026 embedded software cost guide puts a bare-metal sensor build at $2,000 to $5,000, an RTOS application at $4,000 to $12,000, and safety-critical work at two to three times the base, passing $40,000. Treat those as a vendor publishing its own bands rather than independent survey data, but they match the shape of quotes founders report.
The quotes vary so wildly because the scope is almost always undefined when the quote is requested. "Firmware for a sensor board" can mean a 200-line loop or a product with over-the-air updates, power management and a certification file behind it.
Pick this if: you have a funded project and a deadline. Avoid it if: you are still deciding whether the product is worth building, because you will spend real money finding out.
3. Prove it on a dev board, then port
Buy the dev board for the chip you intend to use. Wire up breakout modules for your sensors. Get the whole thing working on a breadboard where every part is known good and every forum post applies to you. Then design a custom board around the same chip family and move the code over.
This is the cheapest genuine shortcut in hardware and it is underused. If the custom board keeps the same microcontroller family, most of the code carries over and the main work is remapping pin numbers. We covered the full process in going from a dev board prototype to a real board.
The catch is that the dev board hides the two hardest steps. Power and clocking are already solved on it, and the breakout modules come with their wiring correct. When you move to your own board, both of those come back, and they come back at the same time.
Pick this if: you have never done this before. It is the lowest-risk order of operations. Avoid it if: your device depends on something the dev board cannot do, like a specific size or power budget.
4. Have the design tool write it
The newest option. If the tool that designed the board also writes the code, it already knows the pin map, the parts and the voltages, which removes most of the ambiguity that makes bring-up slow.
This is what we built into Tovan, and it is in beta. It writes firmware from a plain-language request for the boards it designed, sends the code over a USB cable from Chrome or Edge, and tests it on the real hardware: it reads what the board reports back, asks the sensors questions, and fixes what it finds. Every supported board is in beta, with no exceptions: the ESP32-S3, the Raspberry Pi Pico and other RP2040 boards, the XIAO nRF52840, the ESP32-C3, the ESP32-C6, RP2350 boards and nRF52840 modules. On the heart rate board we used to test it, it found that the sensor samples 52.65 times a second rather than the 50 it had assumed, and corrected its own timing. The full write-up of that run has the detail.
Pick this if: your chip is on the supported list and you want a working first draft on real hardware fast. Avoid it if: you need a chip it does not support, or the work is timing-critical, RF-heavy or certification-bound.
What to have ready before anyone starts
Whichever path you take, these three things decide how smoothly it goes, and all three are free to prepare:
- The schematic and the pin map. Which signal lands on which pin, in writing. Not "it is in the design files." A contractor will charge you to extract this, and you will get it wrong at 2am if you do it yourself.
- The parts, with datasheets. Exact part numbers, not categories. "A temperature sensor" and a specific sensor are different projects, because the second one has a register map and an address.
- A definition of working. One sentence, testable. "The LED blinks once a second when soil moisture is below the threshold" is a spec. "It monitors the plant" is a conversation.
An honest note on AI-written firmware
Embedded is harder for a language model than web code, for a structural reason: there is no feedback loop. A model writing a web app can run it and see what breaks. A model writing firmware traditionally hands you a file and hopes, and if the result is a quiet board, nobody, model or human, knows whether the code or the wiring is at fault.
What changes that is access to the board itself. A tool that can put code on real hardware and read back what the hardware says can check its own assumptions instead of guessing, and that is a different activity from code generation. It is still early. It is board-dependent. It does not help with anything that has to pass a certification lab, and it should not be anywhere near a design where a failure hurts someone.
The sensible way to use it is the same as any fast first draft: read the code, check it against the datasheet, and keep a board on the desk you can actually look at.
FAQ
Do I need firmware if my board has no microcontroller?
No. A purely analog or passive board, a power supply, a breakout, a sensor interface with no processor on it, runs without any code at all. The moment a microcontroller appears, firmware appears with it.
How long does firmware for a simple custom PCB take?
It depends almost entirely on whether the hardware behaves. For a simple sensor product with a known-good board and an experienced developer, the code itself is usually days rather than weeks. The uncertainty is in bring-up, which can be an afternoon or can be most of the schedule.
Can I reuse my Arduino sketch on a custom board?
Often yes, if the custom board uses the same microcontroller family. The usual work is remapping pin numbers and replacing anything that assumed a module rather than a bare part. If the chip family changes, expect a rewrite of the hardware-facing layer and keep your application logic.
Is it cheaper to hire a contractor or learn it myself?
On a single project, learning it yourself is cheaper in cash and much more expensive in calendar time. If you expect to build more than one hardware product, the learning pays back. If this is a one-off and the deadline is real, pay someone.
What makes a firmware quote go up?
Wireless stacks, a real-time operating system, serious power management, over-the-air updates and anything certification-bound. A proof of concept needs almost none of those, and confusing a proof of concept with a shipping product is the expensive mistake in this whole area.
Can AI write the firmware for my board?
For simple behavior on a supported chip, increasingly yes, especially when the tool can test on the real board rather than hand you a file. For timing-critical, RF or safety work, no. Treat it as a fast first draft you still review.
Where to start
If you are at the beginning of this and unsure, do the boring thing: get it working on a dev board first, write down your pin map, and decide what "working" means in one sentence. Every path above gets cheaper once those three exist, including the ones where someone else writes the code.
0 comments