Considerations When Navigating Build or Buy Decisions for Industrial Embedded Control Projects


Deciding on whether you should build or buy components for your embedded project is complicated. You can build controllers from scratch, but that involves huge cost and risk. Yet, off-the-shelf options don’t always meet the specialized requirements for complex industrial applications.

Why not consider a third option, build and buy?

There are several considerations you are likely to encounter when making the decision to build or buy. Discover how a customizable off-the-shelf approach can help you balance the trade-offs given the unique requirements and risks associated with complex industrial applications.



Understanding the total cost trade-offs of building or buying is a difficult but important task. Of course, you must account for cost of your bill of materials (BOM), but there is a lengthy list of short- and long-term costs associated with custom board design that are not always well accounted for.

No design manager wants to be in a situation where the cost of development is underestimated to the point where the project is no longer profitable. But the reality is that development time (and, therefore, cost) is often underestimated—only 41 percent  of embedded projects finish on schedule.

To help you better understand total cost of ownership, here’s a summary of the costs that go into a full-custom control board design:

  • Development:
    • Hardware design
    • Software development (Including including software stack selection, integration, and verification)
    • Mechanical design
    • Selection and management of component vendors
    • Test (including software and hardware test and verification, system performance testing, environmental certifications, shock and vibration, and thermal validation)
    • System integration
    • Documentation
    • Design tools (if you don’t already have them)
  • Manufacturing:
    • Tooling
    • Assembly cost
    • Production test
  • Component Cost
    • BOM
  • Sustaining Engineering
    • Inventory management (this could involve re-designs as components go end-of-life, or cost of keeping an inventory of spares)
    • Software maintenance (OS and driver maintenance, regression testing)
    • Customer support
    • Upgrade cost
    • RMAs

These are a lot of costs to consider! Compare this to a commercial off-the-shelf (COTS) solution. Commercial vendors can not only save you development cost, but also typically use their buying power to purchase components at a much lower price, because they are typically buying in much higher volumes.

Commercial vendors can also off-load sustaining engineering costs. For example, NI’s strong vendor relationships gives us insight into roadmaps that most of our customers don’t have access to. We pass this foresight on to our customers by designing products with very long product life cycles (15 years for CompactRIO products) and seamless upgrade paths. For industrial applications with long field deployments, this type of support is critical.

If a commercial vendor can reduce cost through commoditization, is there ever a situation when the cost of developing in-house would be lower? When evaluating a COTS product that seems too expensive, you should ask:

  • Will I only use a small percentage of the features this product offers?
  • Will I have to “design around”  this product in a way that significantly increases development cost, because it doesn’t fit well into the system?

If the answer to either of these questions is “yes,” the COTS product may be too expensive because it’s just not the right product for you. If the answer is no, it’s probably time to take a hard look and evaluate if you are underestimating your costs, particularly sustaining costs, as these tend to be most overlooked.


End-product volume considerations tie in closely with cost considerations. Most design managers understand that at lower quantities, COTS solutions become more appealing. However, it’s too simplistic to have a blanket threshold and apply it to every build versus buy decision.

The key is determining the “crossover point” where building becomes more profitable than buying. In other words, where the nonrecurring engineering (NRE) cost can be amortized over a large enough quantity that the development cost per unit is offset by savings in component cost. The better you understand all the costs (including sustaining engineering), and factor in the risk of budget and time overruns, the better idea you have of what the true crossover point is.


Crossover point

Keep in mind that most vendors have a pricing strategy for OEM customers that will allow them to scale down prices for higher quantities. This cost savings must also be factored in when evaluating cost.

Time to Market

It is nearly always quicker to buy COTS than to build a custom design.

However, while likely still faster than full-custom design, many COTS options may require a significant amount of software development to maneuver around fixed, vendor-defined functionality.

At NI, the customizability of our platform makes us especially adept at reducing development time, even when compared to other COTS options. On average, design teams who use the NI toolchain complete their projects in about half the time with design teams that are less than half the size. For example, energy storage company, Dynapower, accelerated their development time from 72 weeks to 24 weeks using the NI platform .

There are more advantages to faster development than saving on engineering cost. Getting your product to market faster often leads to increased market share and gives you an advantage over your competitors. In industries where innovation and competition is high, time to market may be critical for your project's success. 

Opportunity Cost

You must also consider the opportunity cost that comes with longer development time. Geoffrey Moore discusses at length the concept of core versus context in the book, Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution. According to Moore:

  • Core is any activity that creates differentiation in the target market resulting in premium prices or increased volume
  • Context is any activity that does not differentiate your company from the customer's viewpoint

Moore further explains, “Core is what companies invest their time and resources in that their competitors do not. Core is what allows a business to make more money and/or more margin, and make people more attracted to a business than to its competitors. Core gives a business bargaining power: it is what customers want and cannot get from anyone else.”

Core vs. Context

Engineering teams often fall into the trap of investing most of their time and effort into tasks that are critical to the success of the application, but aren’t differentiators. In industry, approximately 90 percent of R&D resources are deployed toward non-differentiating tasks. These features are essentially table stakes: customers expect this functionality, there are consequences if it fails, but it doesn’t set your business apart.

To reallocate your resources toward core tasks, you can implement a few strategies:

  • Standardize—Reduce variability in your processes and systems to reduce cost and risk
  • Modularize—Deconstruct a product into modularized subsystems so that components can be reused.
  • Outsource—Drive processes out of your business entirely to reduce overhead

Because the NI platform is both flexible and scalable, you can implement all three strategies listed above. By standardizing on the NI platform, you can reuse code modules and architectures across multiple projects; customize hardware by choosing the form factor and modules for your application; and outsource development, testing, and sustaining engineering costs.

The more you can move your engineering effort away from context, the more you can reallocate valuable engineering resources toward your innovative IP that sets you apart from your competitors.


Embedded design requires a high level of expertise. To build reliable products that the industry expects, design teams must have expertise in:

  • The latest high-density and high-speed chipsets
  • Layout tools that can properly manage the complex packaging and high-speed signaling of components
  • Mechanical software packages that allow for proper design and simulation of components
  • Mechanical and electrical design verification
  • Software test suites and infrastructure for end-to-end validation
  • More…

Cutting corners during any of these tasks during the development process increases the risk of project failure or quality issues down the line.

NI has a long history of designing rugged and reliable COTS products that have been deployed in some of the harshest environments such as oil fields, grid substations, and agricultural equipment . This reliability is because of our best-in-class design, testing, and validation practices. Our ability to deploy reliably into harsh environments is part of our “core.”

Technical Support

Technical support consists of two distinct considerations:

  1. Support needed by the design team from the vendor

For more complex components, vendor support can reduce development efforts and risks to the project. Vendors can provide valuable expertise and support that can save you development time and effort, and can often advise you on design best-practices.

  1. Support that you must provide to your end-customer

In regard to the supportability of your product, the cost of support and RMAs is related to the testing, verification, and documentation that goes into a product before it is shipped. In addition, as designs become outdated (perhaps because the cost of upgrading is too high) access to the right support resources becomes more limited.

Another consideration that impacts supportability is Internet of Things (IoT) compatibility. IoT features such as remote access, system management, and health monitoring have the potential to significantly reduce the cost of field technical support. Innovative features such as predictive maintenance or machine learning can actively prevent system downtime.

Incorporating IoT technology requires additional skillsets in your development and likely requires collaboration with multiple technology vendors that each offer part of the IoT technology stack. NI customers benefit from the partnerships that we have created with IoT technology leaders like Cisco, Intel, and Xilinx, and consortiums like OPC UA and the Industrial Internet Consortium.


For projects with very narrow and highly optimized specifications, the decision tends to lean toward custom design. When your design calls for very high-speed control, or must be deployed in harsh environments, most COTS vendors do not meet design requirements. Generally, COTS options are considered when specifications are more lenient.

However, this is one consideration where NI is quite different than a typical COTS vendor. Our modular design philosophy and software-defined hardware platform places us in the unique position to offer a COTS solution that provides the flexibility and power for highly specific application requirements. How do we do this?

  • FPGA Accessibility—Define hardware functionality in software using FPGAs. You can implement custom control and signal processing with hardware-level timing and determinism.
  • Connectivity—Connect to any signal, sensor, or bus with more than 150 NI and third-party C Series modules.
  • Openness—Leverage a validated NI Real-Time Linux OS with support for LabVIEW and integrate third-party code from Python, C/C++, VHDL, Verilog, and more.
  • Ruggedness—Meet demanding requirements for performance, operating temperature, ingress protection, and vibration.

Because NI customers can customize through software and hardware, we see our platform as an accelerated custom engineering platform rather than a typical off-the-shelf control solution.

See this Lime Instruments application that could only be accomplished with a full-custom control design prior to adopting the NI toolchain.     


As with any design, there are always a few wildcard considerations that can be hard to quantify. Perhaps your company is moving in a new business direction, and your design team is motivated to develop the skills for future use. Or perhaps you have a developer who is passionate about learning a skill that she doesn’t have expertise in today. In these cases, the benefit of designing in-house is still risky, but it could be worth it.

However, maybe a COTS solution has more features than you need today, but it allows you the option to expand your functionality in the future. This might be a good reason to buy a more full-featured COTS option than you might have otherwise considered.


The decision to build or buy is a complex one. The BOM cost is only a small component of the total cost of ownership. When you factor in considerations of risk, platform reuse, expandability, and opportunity cost, it can become even more of a tangled web.

When applications are more specialized and complex, it is rare to see projects with high enough volumes to truly justify the cost of development, test, manufacturing, and sustaining engineering.

The option to buy becomes even more compelling when you consider the NI platform, which is rugged, powerful, and customizable enough for even the most specialized industrial applications. The NI platform is highly differentiated from other commercial off-the-shelf options, which often provide fixed and limited functionality.

As you are making design decisions, consider whether the brunt of engineering effort is being put toward valuable, differentiating features. If most of your effort is going toward low-level tasks that offer no differentiation, it’s well worth considering whether that engineering expense and risk can be reallocated toward tasks that are more “core” to your business.

Next Steps

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, the owner of the mark on a worldwide basis.