Engineers love optimization problems. Finance loves bean counting. Leadership loves cash flow and margin. Putting these together, many product and engineering teams end up with decisions driven by unit cost comparisons, which can be a nefarious for product failure.

Here's the trap: When selecting technology platforms to build on, such as an embedded development or test automation platform, teams fixate on BOM cost. It’s something straightforward to sink your teeth into and base sound, logical decisions off of, right?  Minimize BOM cost. Set pricing. Multiply by forecast volume. Present to leadership. Done.

Except you've optimized the wrong variable.

The Hidden Cost Structure

For complex product and systems that live in the marketplace for years, the true platform cost has multiple factors, not just the price of the per-unit BOM.

Non-Recurring Engineering (NRE): Design, integration, validation, certification. These costs are usually only partially accounted for in the forecasted R&D part of the P&L, in no small part because it can be very difficult to scope technical risk and debt early in projects.

Custom board design can be $200K-500K before you've built a single unit. New ASICs can easily cost $1M+. The sticker cost of that off-the-shelf module may look high, but integration may only be a fraction of the cost of ground-up development.

Unit cost: The number everyone obsesses over, and ironically, the one that matters least early on when trying to build, iterate, and take market share.

Lifecycle cost: These costs can hit in a number of ways: redesigns for component obsolescence, field failures forcing a design update, technical support overhead, new manufacturing tooling and test due to quality issues, etc. These costs accumulate silently over years and can significantly chew into the bottom line.

The math can tell the story. A platform that costs $150 more per unit but saves $300K in NRE breaks even at 2,000 units. This volume may be reasonable for consumer-grade products, but high CapEx, industrialized systems can take years, sometimes even decades, to achieve this kind of volume. By then, the market may have shifted and you could be left with little market share, few real customers, minimal top line cash flow, but a really cost-optimized BOM.

Build vs. Buy: The Real Trade-Off

Custom board design and bespoke ASICs offer theoretical cost optimization at volume. But they frontload massive risk:

• 12-18 month development cycles before first user and revenue

• Complete responsibility for thermal, power, EMI, and compliance

• Embedded and driver software backlogs

• Supply chain management for numerous components across many vendors

• Few mitigation options if requirements change mid-development or early user feedback demands new features

Commercial off-the-shelf (COTS) platforms flip this equation to significantly lighten NRE and sustaining costs:

• Weeks to functional prototype instead of months to spin PCBs and test systems

• Pre-validated reference designs and certifications

• Vendor assumes obsolescence management

• Easy pivots when the product strategy shifts (and it will)

1.“Buy” → launch sooner, profit sooner, mitigate technical risk throughout the product lifecycle

2.“Build” → technical and schedule risk can push you further in the red than expected (risks are much more unbounded)

3.Crossover point may be illusory → what are the implications if you don’t reach that forecasted volume?

Why Teams Get This Wrong

Three systematic biases can mislead key decisions around development approach and platform technology:

1. Overconfidence in volume forecasts. That 10K unit projection in the first three years? It's based on a market model with heroic assumptions. Reality rarely cooperates, and technology markets and buyer preferences are changing faster than ever.

2. Discounting NRE. Finance treats development cost as sunk, so the spreadsheet battle becomes unit cost versus unit cost. This ignores that sunk costs determine cash burn rate and time-to-market.

3. Underestimating complexity. "How hard can board design be?" Harder than you think. “Validating low-level software?” You’ll need a highly experience engineer, not an intern. This doesn’t even begin to encapsulate the schedule risk assocaited with ground-up, custom development, especially when you're doing it for the first time under time-to-market pressure.

The Right Optimization Function

The thesis of this article is optimizing for speed to validated product-market fit, not unit cost, is the best recipe for gaining market share.

Early-stage products face existential uncertainty: Will customers buy this? What is my competition doing? Can we deliver reliably? How is the feature set going to evolve over time?  These questions make people, especially engineers, uncomfortable, because the truth is often impossible to predict and therefore design toward.

Building complex product on commercially available technology platforms de-risk this phase. You get:

• Faster validation cycles

• More iterations before capital exhaustion

• Flexibility to pivot without hardware revisions

• Focus on differentiation instead of commodity platform engineering

Once you've proven the product and scaled past N units, revisit the build decision. At that point you have:

• Validated requirements (no more guessing)

• Capital to fund NRE (revenue funds development)

• Volume to amortize costs (math actually works)

• Team bandwidth (not underwater on core product)

The Counterintuitive Truth

The cheapest BOM often produces the most expensive product, especially for small-to-medium sized engineering teams. Because cost isn't just about the parts list—it's about development risk, time-to-market, and opportunity cost of engineering effort.

Optimize for learning speed early. Optimize for unit economics late. Companies that reverse this sequence don't make it to "late."