A board-level case for treating developer experience like silicon.

Process nodes are converging. IP blocks are licensed from the same handful of vendors. RF front-ends are within a few dB of each other across the entire competitive set. Walk into any MCU or connectivity SoC RFQ today, and the datasheets look more similar than they did five years ago — and they will look more similar still in five more.

So what actually wins the design-win?

Increasingly, it isn’t the silicon. It’s the SDK.

That’s an uncomfortable answer for organisations that still budget the SDK as a cost centre — a deliverable that gets assembled incrementally by a small software team, without a unifying architectural philosophy, until accumulated technical debt quietly becomes a barrier to adoption. By the time leadership notices, it isn’t a software problem any more. It’s a revenue problem.

The data point most executives haven’t seen

Developer surveys across the embedded market consistently rank “quality of software tools and SDK” as the top or second-ranked factor in MCU selection decisions for production volumes under 500,000 units. That ranks above unit price.

Read that twice. For the long tail of embedded design-wins — which is where most volume is concentrated, and where ecosystem stickiness compounds — engineers will pay more per part for a platform whose SDK doesn’t fight them.

For wireless and connectivity SoCs, the SDK weight is even higher. The protocol stack is often inseparable from the SDK itself: BLE host and controller, Thread, Wi-Fi supplicant, Matter cluster models, OpenThread integrations — these aren’t optional libraries customers can swap in. If your SDK ships them poorly, your silicon ships poorly, regardless of how clean the radio is. A connectivity SoC vendor whose BLE stack is undocumented, or whose multi-protocol coexistence configuration is untested, is not actually competing on radio performance; they are competing one rung lower in the buying decision, and they are usually losing.

The asymmetric economics of a developer journey

Consider the financial life of a single design-win.

A developer evaluates your platform. They download the SDK, run a getting-started example, and try to integrate one peripheral or one protocol stack into their prototype. From that point, two paths fork.

In the first, the SDK behaves predictably. Documentation is accurate. Build configuration is one Kconfig change away from the next variant. The HAL doesn’t have undocumented state machines. The OTA pipeline integrates as a first-class subsystem rather than as an application-layer afterthought. The customer ships, scales, and locks in three to seven years of recurring revenue across one or more product generations. They train their team on your platform. Their next project starts on your silicon by default.

In the second, the developer spends the first week fighting opaque build errors. The HAL’s threading model is undocumented. Pin assignments and DMA channel allocations are hardcoded in driver source rather than expressed in board configuration. The OTA pipeline integrates only by reading source code, and the security model has to be reverse-engineered from header comments. Eventually, they either burn margin on integration cost — which they remember at their next refresh cycle — or they migrate to a competitor mid-project. Neither outcome is recoverable through better pricing.

The cost of acquiring that customer was the same in both cases. The lifetime value was not.

Why the SDK gets under-invested

The SDK is the perfect target for under-investment because every individual cut looks rational in isolation.

Documentation can slip a release; the API is the same. Test coverage on a peripheral can be deferred; nobody has complained yet. The build system can keep its idiosyncrasies; the senior engineers know the workarounds. A breaking change to a Kconfig symbol name or a CMake target can ship in a minor release because nobody on the team thinks of those as part of the public API. None of these decisions makes the SDK obviously broken. Each one makes the next decision a little easier.

What this produces, over three or four release cycles, is an SDK that works only for the people who built it. The developers it was supposed to win over — the ones evaluating your platform against three competitors on a Friday afternoon — never make it past the third opaque error message. The cost is invisible because it shows up as deals that never enter the pipeline, not as deals that are formally lost.

What a strategic SDK investment actually buys

Treating the SDK as a platform asset rather than a deliverable changes what shows up on the balance sheet, even if accounting doesn’t have a line item for it.

It buys design-win velocity. A developer who can move from datasheet to running firmware in under thirty minutes is a developer whose project champion has something to show their boss the same day. Design-wins close on momentum. SDKs that produce that momentum compound across the entire pipeline. The “thirty minute getting-started” target is not a marketing slogan — it is the single most consequential page in the documentation set, and the SDKs that hit it consistently are the ones that win the evaluations.

It buys platform stickiness. An engineering team that has internalised your HAL idioms, your Kconfig structure, your debug toolflow, will instinctively start their next project on your silicon. Switching cost works in your favour the moment your developer experience earns the right to it. The reverse is also true: every time a customer has to fork a driver or maintain an internal patch against your SDK, you are training them to view your platform as something they have to work around rather than build on.

It buys ecosystem growth. Component registries with semantic versioning, third-party drivers, community-contributed samples, conditional dependency declarations that pull in only the components a given configuration actually needs — none of these are free, but all of them are unlocked by SDK architecture decisions that look purely technical from a distance. The vendors who choose a component-registry delivery model with reproducible lockfiles get an ecosystem that grows on its own. The vendors who ship monolithic packages, one near-identical archive per product family, find that no amount of developer relations spending compensates.

It buys certification as a commercial moat. A wireless SDK that ships with its BLE Qualified Design listing, its Thread Group certification, and its Wi-Fi Alliance test results — and that documents which exact software version, down to the build hash, corresponds to each listing — gives customers something they can reference directly in their own product certification filings. Without it, every customer must independently qualify the stack, which is expensive and slow. Vendors who do this work upstream collapse weeks or months out of their customers’ time-to-market. That is a benefit customers calculate and remember.
It buys regulatory readiness. The EU Cyber Resilience Act enters enforcement in 2027. ETSI EN 303 645 and NIST IR 8259 are already shaping procurement decisions in regulated markets. An SDK with security designed in from the first silicon generation — Trusted Firmware-M integrated against PSA Certified targets, MCUboot-based secure boot with anti-rollback, OTA pipelines that are atomic, cryptographically authenticated, and resumeable — lets your customers demonstrate compliance. An SDK without it becomes a liability customers route around, particularly as the CRA’s requirement for ongoing vulnerability patching over the device lifetime starts to bite.

The product lifetime question your CFO hasn’t asked yet

Embedded devices have multi-year, sometimes multi-decade, production lifetimes. A product shipped on your silicon in 2026 may need security patches in 2031, long after your mainstream SDK has moved through several major versions and accumulated breaking changes. If you do not have a published Long-Term Support policy — a designated LTS branch per major silicon generation, a committed support window, a backporting discipline for security and critical fixes — your customers are quietly absorbing that risk on your behalf. Eventually, one of them stops absorbing it and routes their next platform decision around you.

This is not a software engineering problem. It is a contractual exposure question, and it should be visible to the CFO and to legal, not just to the SDK team. A formal LTS policy converts an open-ended liability into a bounded, costed commitment. The vendors who have done this work — designating one release per year as LTS, maintaining it on a separate branch with dedicated CI, publishing an end-of-life date that is updated on every patch release — have turned a customer-side anxiety into a sales advantage. The vendors who haven’t are quietly losing renewals they never see lost.

The infrastructure tax that pays for itself

There is one specific investment that under-resourced SDK teams almost always defer, and that pays back faster than any other line item: hardware-in-the-loop continuous integration. A board farm, debug probes, USB-controlled power relays, a serial capture harness, and the test runner that orchestrates them. The capital cost is real but modest. The operating cost is mostly the engineering attention it takes to keep the farm healthy.

The return shows up as customer-reported bugs that never happen. Driver regressions caught before merge instead of in the field. Protocol stack defects validated automatically on every release candidate, instead of being discovered by the first customer to ship at scale. The cost of an HIL CI farm is typically modest relative to the field-defect support load it eliminates over the lifetime of a platform. Treating it as discretionary testing budget, rather than as platform infrastructure, is how SDK teams end up with the worst of both worlds: too much manual testing to ship quickly, and not enough automated coverage to ship safely.

The barrier isn’t technical, it’s organisational

The reason most semiconductor vendors don’t ship best-in-class SDKs is not technical. The patterns are well understood. CMake plus Kconfig for build and configuration. A handle-based or device-tree-based HAL with a clear OS abstraction layer that prevents middleware from accumulating direct kernel dependencies. Trusted Firmware-M and MCUboot for security. OTA pipelines with cryptographic authentication and atomic rollback. Component registries with reproducible lockfiles. Production examples of each exist and serve hundreds of millions of devices today.

The barrier is organisational. SDK architecture requires cross-functional ownership: silicon architects, software engineering, security, developer relations, and product management, all aligned on a multi-year investment horizon. That horizon is at odds with the quarterly release cadence under which most SDK teams operate. It is also at odds with org charts that treat software as a function of post-silicon enablement, rather than a co-equal product. And it is at odds with budgeting cycles that fund SDK headcount against silicon tape-out milestones, rather than against design-win pipeline metrics.

The vendors who fix this — who establish that ownership model, fund it as infrastructure rather than as a discretionary expense, and protect it from the gravitational pull of the next silicon launch — see the return in design-win velocity, customer retention, and ecosystem growth, on a horizon long enough to matter to a CFO.

The question to ask your team this quarter

If you are an executive at a semiconductor company, and you have not asked this question in the last twelve months, ask it now: how much of our forward design-win pipeline depends on the SDK, and who owns it as a product?

If the answer is “we don’t know,” or “the firmware team handles it,” you have a balance sheet asset that nobody is managing.

That is recoverable. But not without naming it as one first.

Your SDK is a balance sheet asset. Is anyone managing it like one?

needCode partners with semiconductor vendors to design, build, and maintain embedded SDKs as platform products — architecture, documentation, HIL CI, LTS policy, and certification artifacts included. If you’re asking whether your SDK is winning or losing design-ins you never see, let’s talk.

Book a free discovery call or get in touch

Further reading