Every embedded developer has been there. A project manager asks: "How long will it take to add CAN bus support?" You think about it for a moment, give a number, and then spend three weeks fighting errata, a buggy HAL version, and a logic analyzer that refuses to trigger on the correct ID. The estimate was off by a factor of three. Again.
Firmware estimation is notoriously unreliable because embedded work has failure modes that pure software projects don't: hardware bugs, toolchain incompatibilities, oscilloscope probes that mysteriously stop working at 4 PM on a Friday, and the ever-present "it worked on the dev board" moment when you deploy to the actual hardware. As a contractor, inaccurate estimates don't just annoy your team — they cost you money and erode client trust.
This article covers the estimation framework I have developed over a decade of embedded contracting. It is not a silver bullet, but it will get you within ±20% most of the time. And that is a massive improvement over the industry average.
The Three-Bucket System
Do not estimate in hours. Human beings are terrible at granular time estimation, especially for technical work. Instead, sort every task into one of three buckets:
| Bucket | Definition | Buffer | Typical range |
|---|---|---|---|
| Known | I have done this exact thing before, on similar hardware, with the same toolchain | × 1.3 | Half a day to 3 days |
| Adapt | I have done something similar, but on different hardware, a different peripheral, or a different vendor SDK | × 2.0 | 3 days to 2 weeks |
| Explore | I have never done this. No one on the team has. The documentation is incomplete or contradictory | × 4.0 | 2 weeks to 8 weeks |
If your gut feeling for a task is "about four days", and it falls into the Adapt bucket, commit to eight days. The buffer covers the inevitable: a confusing register layout, an undocumented errata, a DMA channel conflict with an existing peripheral, or the three days you will spend getting the vendor's SDK to compile with your toolchain version.
Do not negotiate the Explore bucket. If a task is genuinely unknown — a new wireless protocol, a chip family you have never touched, a custom bootloader with no public reference — quote the range and insist on a time-and-materials or phase-gate approach. Fixed-price on Explore work is how contractors go out of business.
The Hardware Factor: Always Add 30%
Here is the single most common estimation mistake in embedded: assuming the hardware works. The dev board works. The reference design on page 42 of the datasheet works. But your actual PCB has a layout mistake, a wrong pull-up resistor value, or a decoupling capacitor placed 12 millimetres too far from the pin. The silicon in your specific batch has a subtle behaviour that contradicts the reference manual.
Add 30% to every estimate for hardware bring-up and debugging. This includes:
- Reading and re-reading the errata document (you did download it, right?)
- Probing signals that should be there but are not
- Reworking the breadboard or prototype because you need a different level shifter
- The time it takes to get an answer from FAE support (usually 48 hours minimum)
On my own projects, I separate the "hardware confidence" assessment into a line item in the estimate. If the client has a Rev A PCB with no previous firmware, I double the hardware factor. If it is a third production run with proven firmware, I reduce it to 15%.
The Communication Trap
Clients do not want to hear that a simple GPIO configuration will take three days. They think GPIO is one line of code and that writing to a register takes a microsecond. They are not wrong — the write itself is instant. What takes three days is figuring out which alternate function number maps to which pin on which package variant, reading the reference manual to confirm the GPIO speed setting does not interfere with the ADC, testing all 16 pins of the port to verify the PCB routing matches the schematic, and discovering that the pin you need is also used by the JTAG debugger.
Here is how I present estimates to clients:
"Adding GPIO control for the user LED will take 3 days: - 1 day: review schematic, datasheet, and alternate function mapping - 1 day: implement and test on the actual hardware - 1 day: buffer for unexpected interactions (it shares a timer channel with the PWM, or the pin is in a different voltage domain) If you want me to commit to 1 day, I can — but the risk of finding an issue that requires a PCB spin is yours, not mine."
This is not defensive. It is honest. Every embedded contractor has a story about the "one-line change" that turned into a two-week debugging session because the new GPIO pin was on the VBAT domain and the reset pull-up was wrong. Name the risk explicitly, and the client will respect you for it.
The Framework I Use
For every firmware project, I build a spreadsheet with three columns: task, bucket (Known/Adapt/Explore), and raw engineering time. Then I apply the multipliers and add the hardware factor on top:
task bucket raw ×mult hw 1.3 total
─────────────────────────────────────────────────────────────
UART bootloader Adapt 5d ×2 ×1.3 13d
I2C EEPROM driver Known 1d ×1.3 ×1.3 ~1.7d
BLE pairing Explore — — — quote T&M
Total estimated: 14.7 days → round to 3 calendar weeks
(assuming no blockers, no holidays, no FAE delays)
Then I add a project-level buffer of 25% on top for integration testing, documentation, and the inevitable "by the way, can you also…" conversation. For the example above, that gives me 3.7 weeks — and I quote 4 weeks.
The client sees 4 weeks and is happy when it takes 3.5. That is infinitely better than quoting 2 weeks, taking 4, and having an unhappy client who thinks you are unreliable.
What Has Worked for Me
Over the years, I have learned a few hard truths about firmware estimation:
- Never estimate on the spot. Any estimate given during a meeting is wrong. Say "I will need a day to think about it and get back to you." Use that day to actually read the datasheet and the reference manual.
- Phase-gate is your friend. For projects longer than a month, break the work into phases: proof of concept (2 weeks), prototype firmware (4 weeks), production firmware (6 weeks). Each phase ends with a deliverable and a go/no-go decision. This protects you and the client.
- Track your actuals. After every project, compare your estimate to the actual time spent. I maintain a private spreadsheet with every project I have done, the estimated vs actual time, and a post-mortem note on what I got wrong. Over time, you calibrate your intuition. I started with an average error of +120% (underestimating by more than half); after four years of tracking, I am down to about +25%.
- Scope creep happens in the last 10%. The first 90% of a firmware project is the fun part — architecture, writing drivers, getting the first peripheral working. The last 10% — edge cases, error handling, integration testing, writing documentation, creating a manufacturing test procedure — takes as long as the first 90%. Quote accordingly.
Practical Checklist
- Sort every task into Known / Adapt / Explore before applying multipliers
- Add 30% hardware factor for bring-up and debugging on new hardware
- Never give an estimate during a meeting — ask for 24 hours
- Break projects over 1 month into phase-gates (PoC → prototype → production)
- Add 25% project buffer on top of the summed task estimates
- Track actuals vs estimates in a spreadsheet — calibrate after every project
- Quote in calendar weeks, not engineering hours. Clients understand weeks
- For Explore tasks, insist on time-and-materials or a fixed-budget spike with a hard stop
Sources
- Steve McConnell, Software Estimation: Demystifying the Black Art — the Cone of Uncertainty applies directly to firmware
- Fred Brooks, The Mythical Man-Month — still relevant decades later, especially the "95% done" trap
- Personal project tracking data (2017–2026) — estimated vs actual time across 30+ embedded projects
📬 Comments / discussion
Prefer email: comments@carrese.eu — include the article URL so I can follow up. For corrections or deeper questions, I typically reply within 48 hours.