BSP Development: Scope, Cost & Acceptance Criteria - A Buyer's Guide
Understanding BSP development — its scope, cost, and acceptance criteria — is the difference between a hardware project that ships on time and one that slips two quarters.
The Board Support Package is the most underestimated line item in any hardware budget. This guide is for the person signing the contract, not the person writing the code. It explains what you are actually buying, what it should cost, and how to write acceptance criteria that hold a vendor accountable when something goes wrong — because something usually does.
Why this guide exists
If you are reading this, one of three things is probably true: your engineering team is overloaded and someone suggested outsourcing the BSP; you have vendor quotes that range wildly in price and cannot tell why; or your last embedded project slipped six months and you do not want a repeat.
You do not need another primer on Linux kernels or device trees — your engineering team can handle that, or read our companion piece on embedded software development services. What you need is the business framework to evaluate BSP scope, cost, and acceptance criteria the way a CFO evaluates any other significant engineering procurement. This is that framework.
What you are actually buying
Strip away the acronyms and a Board Support Package is one thing: the software that makes your specific circuit board boot up and talk to its parts — processor, memory, screen, wireless module, sensors. Without a BSP, none of those components communicate. With a working BSP, your team can finally start writing the product features your customers actually pay for.
The BSP is the foundation everything else gets built on. If the foundation is unstable, you discover it at the worst possible moment — during integration testing, two weeks before a customer demo, when fixing it means unwinding three months of embedded firmware development built on top. A bad CRM rollout is recoverable in a quarter. A bad BSP can kill a product launch. That is why scope, cost, and acceptance criteria matter more here than for most software line items.
BSP development scope: the three things that drive the price
Engineers will give you eight reasons an estimate varies. As a buyer, you need three.
1. How new the hardware is
A mature chip with thousands of devices in the field (NXP i.MX 8, Qualcomm QCS, established STM32 families) means you are buying a port — adapting a well-tested foundation to your board. Predictable scope, predictable price. A new, niche, or still-stabilizing chip means you are buying bring-up — closer to original engineering. Wider price ranges, higher schedule risk. New silicon is sometimes the right business choice, but know which one you are buying before you sign. Our portfolio of past projects shows both.
Ask your engineering team: Has anyone shipped a product on this exact chip with this exact OS before? Can we see their work?
2. How many things are on the board
A four-peripheral sensor product is a different engagement from a multimedia gateway with a screen, camera, Wi-Fi, Bluetooth, and an industrial bus. Peripheral count is roughly proportional to engineering hours — every peripheral needs a driver, every driver needs testing, every test can find a bug. The gap between "we will reuse existing drivers" and "we will write three custom drivers" can easily be $30,000.
Ask your engineering team: How many distinct peripherals are on this board, and how many have ready-made, well-maintained drivers we can reuse?
3. What industry you are in
A consumer-gadget BSP and a medical-device BSP can be technically identical and commercially completely different. Regulated markets — medical, avionics, automotive and industrial safety — require documentation, traceability, and formal testing per standards like IEC 62304. That adds 40% to 100% on top of the base engineering cost. This is not padding; it is the unavoidable cost of proving to a regulator that your software does what you claim. If you are buying a regulated BSP and the quote does not explicitly include regulatory documentation work, the quote is incomplete — you will pay for it later, at a worse rate, under time pressure. See the industries we serve for how regulatory scope changes a project.
BSP development cost: what you should actually budget
Most vendors will not publish ranges. We will, because vague pricing is how buyers get hurt. These reflect typical engagements at experienced North American and Western European rates, assuming a single board, a defined scope, and a buyer who has done the homework above.
Simple sensor or controller
Small MCU, few peripherals, no OS or a basic RTOS. Typical budget: $10,000 – $40,000
Connected product with RTOS
Cortex-M class chip, moderate peripheral count, FreeRTOS or Zephyr. Typical budget: $20,000 – $60,000
Embedded Linux on a single-board computer
Application processor, 10–15 peripherals, mostly off-the-shelf drivers, Yocto or Buildroot included. Typical budget: $40,000 – $120,000
Complex Linux with custom hardware
Multi-core application processor, display, camera, wireless, custom peripherals. Typical budget: $80,000 – $200,000+
Porting an existing BSP to a new board revision
Same chip family, minor schematic changes, re-validation. Typical budget: 30–50% of the original cost
Regulated product surcharge
Applies on top of any tier above, depending on safety class. Add 40–100%
When a BSP quote should make you nervous
Far below the range almost always means underscoping — the vendor hits the real cost mid-project and returns with a change order, and the total ends up above the realistic quote you turned down.
Far above the range with no explanation means either the vendor spotted real risks the cheap quotes missed, or they are charging premium rates for standard work. Ask them to walk you through the assumptions.
A firm fixed price on a chip released in the last six months — nobody has enough data to fix-price brand-new silicon. The vendor is inexperienced or about to surprise you.
No mention of the hardware revision the price assumes — respins are normal, and a quote that does not specify the board revision will be re-negotiated when the next one arrives. This ties directly into your system architecture decisions.
How to compare quotes that look different
The most common buyer frustration: three quotes that all say "BSP development" and arrive at three different numbers. The cause is rarely greed — each vendor is quoting a different scope, and most quotes do not make that scope explicit. To compare apples to apples, ask each vendor, in writing, for:
- The exact list of peripherals they plan to support
- The operating system and version they will target
- Deliverables beyond the binary: source code, build system, documentation, test scripts
- The hardware revision the price assumes — and what happens if a respin is needed
- Whether acceptance testing is included or billed separately
- Post-delivery support included: 0, 30, 90 days, or longer
- Who owns long-term maintenance for kernel updates and security patches
A quote that addresses all of those is a quote you can compare. A quote that does not is a sales pitch dressed up as a proposal.
BSP acceptance criteria: the most important document in the contract
This is the section most buyers skip — and most regret skipping. Acceptance criteria are the written definition of what "done" means. They are not a technical document; they are a contract tool. When something goes wrong six months in, the acceptance criteria decide whether the dispute is resolved in an afternoon or escalates into a six-figure argument.
A good criterion has four parts: what is tested, how it is tested, what counts as passing, and what hardware/software version the test runs on.
Bad: "The Wi-Fi shall work correctly." Unenforceable — "work correctly" means whatever the side defending it wants. No test, no threshold, no environment.
Good: "The Wi-Fi module shall maintain a stable connection to a reference access point for 24 continuous hours, sustain at least 30 Mbps throughput during that period, and recover automatically within 10 seconds of a simulated access-point reboot. Tested on Hardware Revision B with the delivered BSP image." A specific scenario, a measurable threshold, a recovery requirement, a defined environment. Pass or fail is unambiguous.
You do not need to write these yourself — your vendor should propose them. If a vendor resists writing testable criteria, be cautious.
The five criteria every BSP contract should include
- Boot performance — time from power-on to a usable system on the target hardware.
- Each peripheral — one criterion per major peripheral, with measurable thresholds.
- Power management — sleep, wake, and consumption targets, if battery life matters.
- Stability under load — survives a defined stress test, typically 24–72 hours.
- Reproducibility of the build — your team can rebuild the exact delivered image from source on a clean machine using the delivered instructions.
The last one is most often overlooked. A BSP you cannot rebuild without the original vendor is a BSP that has locked you into that vendor for the life of the product.
Build vs. buy: when to outsource
For most hardware companies — especially startups and first-generation products — outsourcing BSP development is the lower-risk call, for three reasons:
- BSP work is intermittent. Intensive for three to six months, then sporadic maintenance for years. Hiring full-time specialists for intermittent work is expensive and hard to retain.
- BSP work is specialized. A firmware engineer who writes excellent application code may never have brought up a Yocto-based Linux system on custom silicon. Many companies bring in specialists for the firmware design and BSP layer.
- The downside is concentrated. A bad application feature slips one feature. A bad BSP slips your launch.
Keeping it in-house makes sense when BSP work will continue across multiple products for years, you already have senior embedded Linux engineers on staff, or your product depends on proprietary IP in the BSP layer.
Before you call vendors
Get clear internal answers first. If you cannot answer these, you are not ready to compare quotes — you are ready for a scoping conversation:
- What chip have we chosen, and has anyone shipped a product on it before?
- Is the schematic finalized, or still changing?
- What operating system have we chosen, and why?
- Are there regulatory requirements affecting the BSP?
- Who on our side owns the vendor relationship day-to-day?
Red flags in a vendor conversation
- They cannot name recent BSP projects — a credible vendor explains what chips they worked on, what products they supported, what problems they solved. See portfolio examples.
- They do not ask to see your schematic — anyone quoting from a paragraph description is guessing.
- They do not mention acceptance criteria — either they do not work this way, or they hope you will not push for it later.
- They explain their process only in jargon — ask "how do you handle a missed milestone?" If the answer is purely technical, they are not used to working with buyers.
- They refuse to discuss past schedule slips or respins — every experienced vendor has dealt with both; the good ones are transparent about how.
Frequently asked questions
How long does BSP development take realistically?
A simple BSP can be delivered in four to six weeks. A complex embedded Linux BSP on custom hardware typically takes three to six months from signed contract to acceptance; regulated products take longer. The biggest source of delay is hardware availability and board revisions.
What is the typical BSP development cost for a startup?
Most hardware startups land in $40,000–$120,000 for embedded Linux BSPs and $15,000–$50,000 for microcontroller-based products. The biggest variable is whether the silicon platform is mature or still stabilizing.
Can we change vendors partway through?
Yes, but it is expensive. Switching mid-project typically costs 40–60% of the original engagement value, because the new vendor must audit and often rework the delivered BSP.
Who owns the code at the end?
You should. Every contract should specify that the customer owns the source code, build configurations, and documentation, with no ongoing licensing obligations. If a vendor wants to retain ownership, treat that as a major warning sign.
Do we need to be technical to manage a BSP engagement?
No — but you need someone technical reviewing the work. The buyer can be a VP of Engineering, a founder, or a product manager; the reviewer should be an engineer capable of validating acceptance test results.
How should we handle BSP maintenance after delivery?
Three common models: a vendor retainer (typically 10–20% of project value annually); internal ownership after handoff, with the vendor on call for escalation; or case-by-case support. The wrong option is no plan at all — security and compatibility debt accumulates quickly.
Ready to scope your BSP development project?
If you are evaluating BSP vendors and want a second opinion on the quotes in front of you — or help scoping the work before you talk to vendors — that is the conversation we have every week. We will review your schematic, chip choice, timeline, and risk areas, and tell you honestly what the cost should be, what the realistic schedule is, and where the risks are. If we are the right fit, we will tell you. If we are not, we will tell you that too.