Choosing a Firmware Development Partner: 9 Questions to Ask
Firmware development services are easy to buy badly. The work is hard to evaluate from outside, the deliverable is invisible until it fails, and problems typically surface after the engagement ends.
These nine questions separate teams that will hand you a maintainable product from teams that will hand you a liability.
1. Who owns the code, and what is in it?
Get this in writing before anything else.
Ask specifically whether the deliverable includes third party libraries, and under what licences. A GPL licensed component inside your shipping firmware creates obligations you may not want.
Ask whether the firm reuses internal frameworks across clients. That is not necessarily bad, but you need to know whether you are receiving a licence or ownership, and what happens if the relationship ends.
2. What does the handover actually include?
"We will deliver the firmware" is not a specification. A complete handover includes:
- Full source, in a repository with real commit history rather than a single dump
- Build instructions that work on a clean machine
- Toolchain version pinning, so the build reproduces in two years
- Hardware setup documentation
- Test procedures and any test fixtures
- Known issues and limitations, written down honestly
Ask to see an example handover package from a previous project, redacted. A firm that has one will show it. A firm that does not will explain why it cannot.
3. How do you test?
This question separates most of the field.
Listen for specifics:
- Unit tests on logic that can be tested off target
- Hardware in the loop testing for anything timing or peripheral dependent
- Continuous integration that builds every commit
- A defined process for regression testing before release
"We test thoroughly" is not an answer. Ask what percentage of the codebase has automated coverage and how long the test suite takes to run.
4. Do you have the hardware?
Firmware developed against a simulator or an evaluation board is not firmware developed against your product.
Ask how many units of your actual hardware the team will have, and who pays for them. Ask whether they have the bench equipment relevant to your product: an oscilloscope, a logic analyzer, a current measurement tool for low power work, a VNA if RF is involved.
A firm doing low power work without a proper current measurement setup cannot verify your sleep current claim, and you will discover that after production. For sleep current testing standards, see our guide on low power circuit design.
5. Who specifically will do the work?
Sales engineers and delivery engineers are frequently different people.
Ask for the names and backgrounds of the engineers assigned. Ask whether they are dedicated or shared across projects. Ask what happens if that person leaves mid project.
Ask to speak with the engineer, not just the account manager, before signing.
6. What is your experience with this specific silicon?
Embedded work is not generic. A team fluent in Linux application development on an application processor may have little experience with bare metal work on a microcontroller, and the two are genuinely different disciplines.
Ask for prior work on the same family. Ask about the specific peripherals your design depends on. If your product uses a sub-GHz radio, ask whether they have brought one up on the bench and characterized its output, or only used a vendor library. Read our STM32WL LoRa design guide for an example of silicon-specific bring-up discipline.
7. How do you handle firmware updates in the field?
If this is not part of the plan from the start, it is expensive to add later.
Ask what update mechanism they propose, whether it supports rollback on a failed update, how the image is authenticated, and how much flash the scheme consumes. A design without rollback protection will eventually brick a customer's device.
8. What is the change process?
Requirements change on every project. What matters is how that is handled.
Ask how change requests are scoped and priced, what the typical turnaround is, and whether small changes require a formal amendment. A process that makes minor changes expensive will make the project adversarial.
9. What happens after delivery?
Ask about the warranty period, response times for defects found after handover, and rates for future work.
Ask what happens if a defect appears eighteen months later. The answer tells you whether you are buying a project or a relationship.
Warning signs
A fixed price with no discovery phase. Embedded work has unknowns. A firm quoting a firm price without investigating your hardware is either padding heavily or planning to raise change requests later.
No questions about your hardware. A serious firm will want the schematic, the datasheets and ideally a unit before quoting.
Reluctance to discuss testing. Teams with good practice enjoy talking about it.
No named engineers. If you cannot find out who will write the code, you cannot evaluate whether they can.
Estimates without ranges. "Twelve weeks" is a guess presented as a fact. "Ten to sixteen weeks, with these three unknowns driving the spread" is an estimate.
What to prepare before you approach anyone
You will get better quotes and better outcomes if you arrive with:
- Schematics and a bill of materials
- A written requirements document, even a rough one
- Your power and performance targets, stated as numbers
- Certification requirements and target markets
- The real deadline and what drives it
Firms that can quote accurately need this. Firms that quote without it are guessing.
Working with SRQ Robotics
SRQ Robotics develops firmware for embedded and RF products, including sub-GHz radio bring up, low power designs with validated energy budgets, and sensor fusion for motion tracking. We work from schematic through to pre-compliance testing, and we hand over source, build environment and test procedures as standard.
Learn more about our Embedded & IoT services or get in touch with your schematic and targets and we will tell you what we think it takes.