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.
(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.