The Make vs. Buy Spectrum: Choosing the Right Product Development Path
Every product development program starts with a deceptively simple question: How much of the device should you build yourself and how much should you buy? There is a spectrum between finished off-the-shelf (OTS) products and fully custom designs. Choosing the right path, before committing engineering dollars, is one of the highest-leverage decisions in the entire development cycle. At F3, we can help you sort through options so you have the information you need to decide.
Beyond Make vs Buy
Traditional framing pits two extremes against each other. On the buy side, an off-the-shelf (OTS) product that already does the job can quickly deploy it as-is, accepting that it is usually overkill for the mission and carries cost, size, and features you do not need. On the build side, a fully custom device delivers the lowest unit cost at volume, the exact feature set your use case demands, unique differentiating features, and intellectual property ownership. Considering only these two extremes skips the middle ground where many products actually belong. The reality is a continuum of multiple paths, each striking a different balance of speed, cost, control, and risk.
Common deployment options:
- Existing finished product. You buy a complete, certified device and deploy it as-is. This is the fastest route to market with the lowest up-front cost, but you inherit the vendor’s roadmap, feature set, unit cost, and revision schedule. It is well suited to prototypes, pilots, and small volumes. It also provides for zero differentiation, as anybody can do the exact same thing.
- Integrate off-the-shelf parts. You design your own product but drop in OTS parts, such as a cellular, Wi-Fi, or Bluetooth radio, to cover the hardest, highest-risk parts. This is also where you’d use a System on Module or similar for your CPU. You control the enclosure, application, and overall design while shortening the RF and certification effort. It is a strong balance for medium volumes. You own the IP of the assembly, but almost all your OTS parts are single source because of their integration level.
- Custom development. You design your own product, which is itself a spectrum rather than a single choice. Toward one end, you assemble larger proven blocks, combining known-good system elements into a whole that meets your requirements to add speed and cut risk. Toward the other end, you optimize from the ground up, deciding every part of the system for the mission. In any case, the resulting IP is yours, and you reuse the low-level building blocks nobody would sensibly reinvent.
| Path | Speed to market | Up-front cost | Unit cost at volume | IP control | Best fit |
| Use finished product | Fastest | Lowest | Highest | Vendor | Prototypes, pilots, small volume |
| Integrate OTS parts | Fast | Low to moderate | Moderate | Shared | Medium volume; RF/cert shortcut |
| Custom development | Moderate | Moderate | Low | You | Medium to large volume; your architecture |
This Is The Way
Every product reuses IP. Even a fully custom design reuses schematic and firmware IP that would be foolish to reinvent, like a compliant power front end or a proven comms stack. So the real question is never whether you reuse IP. It is two things: How large are the blocks you reuse and how much of the architecture should you own and optimize?
Toward the reuse end of custom development, you start from larger proven blocks: a reference platform, a subsystem, a module, or a known-good section of a prior design. Then you adapt them, keeping their CPU, RTOS, power, and form-factor choices if they meet your needs. This is most of what F3 does: combine trusted system elements to meet your requirements and buying speed, and lower risk while you keep the resulting IP.
Toward the optimize end, the architecture is derived from your requirements and every axis is tuned to the mission. Take an OBD++ interface device: a custom connector and enclosure; an ISO-16750 load-dump-compliant power system; perhaps a different RTOS chosen for your needs and often industrial design to optimize size, weight, and user experience. It still reuses the schematic and firmware IP that it doesn’t make sense to reinvent, the smaller, more universal blocks, and decides more of the system itself.
Wherever you land on this spectrum, be clear about what a published reference design or eval platform is: a starting point, not a product. Turning it into a manufacturable, certifiable, mission-fit product is exactly the engineering that remains, and it’s what we do.
Actual Deciding Criteria
There is no universal right answer, only the right answer for your product. At F3, we weigh the following criteria with clients:
- Expected volume. The single biggest driver. Prototypes and small runs favor buying or integrating; customization and custom builds of medium to large volumes usually see lower unit cost.
- Target unit cost. OTS hardware carries a premium. A device that costs $200+ per unit OTS may cost about $50 once it is designed to specifications. Typically, device volumes run into the 2k to 5k range before breaking even – and that’s over the product’s lifetime.
- Form factor and size. The smaller and more embedded the device, the more a custom or customized design pays off, since OTS hardware is often larger than the application needs.
- Power consumption. Battery life and thermal budgets frequently rule out feature-rich OTS boards that draw more than your use case allows.
- RF performance. Antenna placement, sensitivity, and coexistence often demand more control than a finished product allows. When your device is small, you can only use an OTS antenna if you design your whole product around it. Otherwise, you’ll need a custom antenna.
- Intellectual-property control. Building or customizing yields IP you own, which differentiates your product and adds tangible company value your competitors do not have.
- Certification burden and timeline. Reusing a pre-certified module or proven IP can dramatically cut regulatory time and cost compared with certifying a design from scratch.
- Sourcing and supply-chain risk. A specialized OTS product may be available from zero or only a few vendors, shrinking your pool of partner options and forcing you to make compromises.
- Lifecycle and long-term support. How long you must keep shipping, and how much control you need over revisions and end-of-life, can outweigh any day-one savings.
When the Fast, Cheap Option Costs the Most
The seemingly low-cost path can quietly become the expensive one. A finished product or module you do not control is subject to vendor decisions, such as:
- Discontinuation. If the OTS hardware is discontinued, you must spend time and engineering effort finding a replacement, an unplanned cost.
- Forced recertification. When a vendor revises a module or board, surprise revision changes can force a redesign, reconfiguration, and recertification of your product on the vendor’s timeline rather than yours.
- Loss of control. Future lead times, revisions, and pricing are out of your hands. As our original white paper puts it, when you buy a product you are not in control of the destiny of that product.
- Feature-bloat cost. Paying for components and functionality your project doesn’t need adds to unit cost without adding value.
None of this means buying is the wrong call. It means the total cost of ownership across the product’s life, not the day-one price, should drive the decision.
Be Informed and Decide Early
Aim to sort out options before the requirements are finished. Start with a clear business case and a written requirements document describing exactly what the device must do. Without it, any decision is a guess. We can save you months of work and hundreds of thousands of dollars with a week of consulting about requirements we see all the time.
F3 designs and develops custom electronics products built for volume, high-value, and mass-production-ready deployment. We help clients examine every option, from an OTS-based design to a fully custom solution. Call or email and our sales team will get you in contact with an engineer to get answers.