Build or Buy? The Design Rules Remain the Same

The last time I visited the “build or buy” issue, a lot of small commercial engineering outfits were looking to the big companies for in-house support for their various products for the burgeoning wireless market.

With the technology and complexity of self-contained RF systems having advanced much in the past 15 years, I'm sure the major IC companies and module makers still get involved with the little guy but the details are usually sparse due to the nature of today's non-disclosure agreements. On the other hand, build-versus-buy is largely the same issue at university labs and applied-research houses, where performance isn't necessarily measured in commercial terms and where meeting tight timetables and cost budgets aren't always the biggest driving factors.

So what are the general design rules? I reckon they're largely unknown to the current crop of today's young engineers, but they are relatively simple and unchanged, albeit counter-intuitive.

Buy if you have a low-volume application. Why buy? Because, beyond the proof-of-concept prototype phase, in-house systems designers in a small company tend to equate overall system cost with component/board cost. They often disregard the cost of research and development that could well run to half a million dollars or more for a small production run.

At the other end, build if you have a relatively high-volume application that needs to be customized to a specific need, you have the time to develop the design, and the resources (designers and test equipment) at hand. But beware, too — if it's an RF application, consider sticking to basic oscillators, mixers, and IF amps especially if the project is going commercial, because advanced RF expertise and experience with FCC licensing is tough to come by in-house. And certainly, let the pros handle advanced mixer systems, frequency synthesizers, and spread-spectrum chips.

Approach software development with caution. Many designers today appear to favor C++. Know your software or know your software engineers well. Do these things, and your overall costs might well drop by 80 percent or 90 percent in some applications.

What's the critical volume (VC ) at which it becomes preferable to build versus buy? It could be less than a hundred to a few thousand; it ultimately hinges on the calculated total cost per sample that you can put up with. This graph sheds a bit more light on the analysis.

While system performance tends to improve with available design time, the overall do-it-yourself cost per sample (corresponding to a critical volume of production, VC) usually determines the outcome of a make-or-buy decision. 
(Source: drawing by Vincent Biancomano; published originally in Portable Design, March 1999)

While system performance tends to improve with available design time, the overall do-it-yourself cost per sample (corresponding to a critical volume of production, VC ) usually determines the outcome of a make-or-buy decision.
(Source: drawing by Vincent Biancomano; published originally in Portable Design, March 1999)

If it's an RF-related project, it shouldn't take long for you to determine which way to go — a few days at most if you have no RF experience (or are RF-competent and realize you're in over your head) to a few weeks if you have the experience and resources but need to do a detailed cost breakdown. Product design cycles can be extremely short today — if your application is designed to go commercial and you take a few months to decide what to do, you may miss the boat.

Build-versus-buy considerations are different for academic labs, which often pool their resources from several departments. They favor off-the-shelf solutions that can be adapted to custom requirements for student kits and modules, and where commercial-level performance isn't the key factor. “I don't think much has changed for us in general,” says Fraser Robertson, manager of Electronics and Audio Visual Production for Maths Computing and Technology Faculty at the Open University in Milton Keynes, UK. “There's no point in reinventing the wheel.”

But some things have changed. The technology, he tells me, cuts twice — beyond improvements in technology rendering previously useful in-house devices obsolete, prototyping can be more difficult because surface-mount components are widely used today. In the former case, he has sometimes, for example, been forced to abandon the use of otherwise good small general-purpose DC/DC converter modules used in low-quantity research support in favor of alternative solutions where a parameter such as low-noise performance is critical.

As to circuitry, Robertson (as many others) believes a discrete design can still outperform a module or pure IC solution partly because it can be optimized to meet specific requirements. “Conversely, in most cases it would be difficult to improve on the performance of ICs and modules,” he says. But do you have the time to develop your discrete design? If so, carry on.

10 comments on “Build or Buy? The Design Rules Remain the Same

  1. Vishal Prajapati
    May 23, 2013

    This has been the debate for almost every one from SME to PSUs. Probably PSUs don't have problem building a product from scratch as they have enough resources for that. While SMEs have big confusion on which way to go. This is endless debate and can never draw sharp line from where build or buy can be switched. These are my views.

  2. bjcoppa
    May 23, 2013

    Speaking of design, I find it interesting how ARM has taken over the apps processor world, licensing out its chip architecture & dominating the mobile device world.  It owns no fabs and doesn't even outsource production to a foundry and strive to a fabless chip leader like Qualcomm. It has been able to stay lean and mean on the design front and held out companies like Intel for the longest time. Instead of starting with a business model centered around PCs like Intel, it saw the writing on the wall long ago and jumped on the mobile computing bandwagon and reeled in the herd globally.

  3. Netcrawl
    May 24, 2013

    @analoging you're right! ARM is doing a great job, it provide a low cost rapid platform for SoC platform(probably the best in the industry). Its driving a whole new number of the world's fastest growing market spaces and its partners that makes the direct market impact on the semiconductor space, and still doing great.

  4. bjcoppa
    May 24, 2013

    In some ways, ARM has a benefit from solely focusing on designing chips for its core applications. It does not have to worry about all of the issues surrounding maintaining a fab and outsourcing production. They can simply maintain a laser-like focus on designing the best chips for mobile devices on the planet (analog or not)- no pun intended.

  5. Brad Albing
    May 27, 2013

    @analoging – just to clarify this: It owns no fabs and doesn't even outsource production to a foundry and strive to a fabless chip leader like Qualcomm – do you mean ARM just sells its IP (but that's all)? Interesting business. I'm trying to think if there are any companies that are pursuing the selling of integrated analog IP in the same manner.

  6. jkvasan
    May 28, 2013


    Buying individual modules and building the design can reduce time-to-market. However, as I read from a recent blog “Remove the 'Frankenstein Effect' from Medical Devices, if care is not taken, 'parts selected for their unique special functions without regard for their perfect interoperability' , could have a negative impact.

  7. Brad Albing
    May 28, 2013

    And there is another conflict (beyond the buy or build issue) that you must deal with – which is more important – the special features of a part or subsystem that make it just right for your project/product; or the need to make your project/product interoperable with plenty of other devices on the market – which forces you to use more generic parts and more generic interfaces; and means what you end up designing/building is generic, dull, and completely not leading edge technology. Certainly a dilemma.

  8. vbiancomano
    May 28, 2013

    @jayaraman, Yes, as implied here (and stated outright in our previous look at the subject), the “Make or Buy” issue has no hard-and-fast rules. It relies on some basic rules-of-thumb, i.e., general guidelines, that need to be balanced against economic realities. In that sense, the question creates some degree of “endless debate,” as initially voiced by Vishal because, to begin with, the economics may not be the same for the various design houses. Additional design considerations such as the tradeoffs that result from using a less than “perfect” component for a given job might well make the decision to “build or buy” all that more difficult. 

  9. jkvasan
    May 29, 2013


    This has always been the Designer's Dilemma. Using generic interfaces is like, building software with those ready made commands (Labview) and sometimes can get us into trouble.

    Speed and range could be a big issue when integrating two generic sub-system for a specific application.

  10. jkvasan
    May 29, 2013


    I have always seen trade-offs happening when integrating sub-modules, chips to form a specific architecture. What is true for one application may not always be apt for another.

    Sometimes this could even affect the signal/data in question, by introducing timing related issues such as signal delays and phase differences etc.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.