Custom vs COTS On-Board Computer: When Building Your Own Pays Off
Buy an off-the-shelf on-board computer when it covers the mission's computing power, interfaces and environment. Design a custom one when your interfaces do not exist on the shelf, or when you need to own the IP and control manufacturing long-term. A custom design with spare FPGA logic can gain functions later: on Latitude's launch-vehicle computer, InTechHouse later used spare FPGA resources to add GPS time synchronization.
Key takeaways
- COTS is the default choice when a unit covers your computing power, interfaces and environmental conditions. It is fast and cost effective.
- Go custom when your interface requirements come from the rest of your system and nothing on the market matches them.
- A custom board carries non-recurring engineering cost that pays back at scale; COTS suits low volumes and prototypes.
- An FPGA leaves room to add hardware functions after the board is closed, which a processor's fixed peripherals do not.
- Owning the intellectual property keeps manufacturing under your control for the years the computer stays in service.
The short answer: buy off the shelf if it covers your mission
A commercial off the shelf (COTS) computer is the right choice when it already meets the mission. We design custom on-board computers for a living, and our Vice CTO still puts it this way:
"If an off-the-shelf computer covers your mission (computing power, interfaces, environmental conditions), you're probably better off buying it. But if your interface requirements come from the rest of your system and nothing like that exists, it's better to design it."
Adam Szychulec, Vice CTO, InTechHouse
That gives you three checks to run against any COTS candidate:
- Computing power. Does the processing performance and memory cover your software, with margin for future features?
- Interfaces. Does it have every connection your vehicle needs, in the form your system expects?
- Environmental conditions. Is it rated for the temperature, vibration, shock and pressure your platform will see?
If the answer is yes to all three, COTS products are usually the better option. If one answer is no, keep reading.
What a COTS mission computer gives you
COTS mission computers are mass-produced, pre-assembled designs, and that brings real benefits:
- Speed. Lead times are short, and integration can start as soon as the unit arrives.
- Existing documentation, and often existing qualification data from the vendor.
- A known software stack, with drivers and board support that other customers already use.
- A predictable unit price, which suits low volumes and early prototypes.
- Proven, rugged and modular platforms for many applications, including industrial controllers and defense vehicles, with reliability data from units already in the field.
The limits come with the same package: a fixed I/O set, fixed size, weight and power, and a lifecycle the vendor decides. A COTS board can also be overspecified for your scenario. You pay for features you do not use, and unused interfaces still draw power and take space.
InTechHouse also builds on COTS single-board computers (SBC) when that is the right call.
Six factors that decide custom vs COTS
Six factors decide most custom vs COTS choices. Each one below has a single rule you can apply to your own platform.
Interfaces your system requires
Your interface requirements come from the rest of the system: the sensors, actuators, radios and buses already chosen for the vehicle. If no COTS board matches them, design the computer around them instead of designing the vehicle around the board. Adapters and extra boards can bridge small gaps, but each one adds mass, power consumption and another point of failure. A board designed to meet your interfaces directly is usually the more efficient of the two solutions.
Peripherals you can add later
A processor has a fixed set of peripherals. That covers its external interfaces and its internal ones, such as hardware accelerators. Once the board is closed, that set is all you get. An FPGA leaves room to add hardware functions later, allowing new functionality without a board respin, which is why custom designs with programmable logic offer a kind of adaptability that a COTS processor board cannot match. We cover this in depth in FPGA SoC on-board computer architecture.
Production volume and unit cost
COTS suits low volumes and prototypes, because you pay only the unit price. A custom board carries non-recurring engineering cost and a longer lead time before the first unit. That investment pays back at medium to high production volume, where a leaner bill of materials reduces the cost of every unit you build. The more units you plan, the stronger the case for custom.
Qualification burden
A COTS unit may come with the vendor's qualification data, but that data covers the vendor's test conditions, not necessarily yours. A custom unit needs its own qualification campaign, and that campaign is part of the project cost and schedule. Check what compliance evidence a COTS vendor can provide before you assume it transfers to your program. For what a campaign involves, see our guide to on-board computer qualification.
Lifecycle and obsolescence
On-board computers in aerospace and defense stay in service for many years, and COTS boards face availability issues when the vendor ends production. Some FPGA families from the major vendors stay available for decades, because they serve military and space programs. Altera, for example, extended lifecycle support for its Agilex, MAX 10 and Cyclone V families through 2045 (Altera, 2026). That longevity is why some designs are built on an FPGA even when a processor five or ten times cheaper could do the job. The trade-off is real on both sides: you pay more per chip to buy years of supply. More on managing this in our article on FPGA obsolescence.
Ownership of the design
With COTS, the design belongs to the vendor, and so does the decision whether it stays in production. With a custom design you own the intellectual property (here IP means intellectual property, not an FPGA IP core), and you control the bill of materials and where the board is made.
"It isn't only about the technology. Owning the intellectual property, and always being able to manufacture your own hardware, makes you independent of outside suppliers."
Adam Szychulec, Vice CTO, InTechHouse
Owning the design does not remove component obsolescence. It means you can respond to it yourself, by re-sourcing a part or revising the board, instead of waiting for a vendor.
The middle path: a system-on-module on a custom carrier
A system-on-module (SoM) on a custom carrier board sits between the two options. The COTS compute module keeps the processor and memory qualified by the vendor, while the carrier board gives you the I/O, form factor and connectors your system needs. It is a modular, flexible approach: you get customization where it matters and keep a proven core. The trade-off is that the module's lifecycle is still set by its vendor.
A custom example: spare FPGA resources put to work on Latitude
InTechHouse case study: Latitude on-board computer
InTechHouse delivered the complete hardware of the on-board computer for Latitude's Zephyr launch vehicle, including FPGA IP cores for time and frequency synchronization. After the board was designed, spare FPGA resources were used to add time synchronization with the GPS signal and correction of internal time to clock cycles. Those mechanisms were later used to implement the time synchronization functions, without changing the board. That is the flexibility a COTS processor board with fixed peripherals could not offer. Latitude describes the result as "a fully qualified On-Board Computer for space vehicle."
If you go custom, make sure the IP transfers to you
The ownership argument only holds if your supplier hands the IP over. Ask for it in the contract, together with the design files and test reports.
"When we design a custom on-board computer, the IP and the full documentation go to the client. They own it, they have the documentation, and they can come back to it."
Michał Kierul, CEO, InTechHouse
For the full checklist, read how to choose an on-board computer development company.
Decision table: COTS, custom or system-on-module
Let's talk about your next move
Not sure where to start? We work with companies at every stage, from early ideas to enterprise-level builds. A 30-minute call can save you months of guesswork.
FAQ
Should we buy a COTS mission computer or develop a custom one?
Buy a COTS mission computer if it covers your computing power, interfaces and environmental conditions; it is faster and usually more cost effective. Develop a custom one when your interface requirements are not met by anything on the market, when you plan medium to high volumes, or when you need to own the design long-term.
When does a custom on-board computer make sense?
A custom on-board computer makes sense when your system needs interfaces no COTS board offers, when production volume is high enough to repay non-recurring engineering cost, or when you need to own the IP and control manufacturing. Spare FPGA logic also lets a custom design gain hardware functions after the board is built.
What are the hidden risks of an off-the-shelf on-board computer?
The main hidden risks are lifecycle and fit. The vendor decides when production ends, which can force a redesign mid-program. COTS boards may also be overspecified, so you pay for unused features and interfaces that still draw power. Vendor qualification data covers the vendor's conditions, which may differ from yours.
Is there a middle path between COTS and fully custom?
Yes. A system-on-module on a custom carrier board combines a vendor-qualified compute module with a carrier that provides your I/O, form factor and connectors. You get customization where your system needs it and keep a proven processing core, but the module's lifecycle still depends on its vendor.
Who owns the design of a custom on-board computer?
The owner depends on the contract, so agree it before work starts. At InTechHouse, the intellectual property and full documentation of a custom on-board computer go to the client, including design files and test reports. That lets you manufacture the hardware where you choose and revise it years later.
Adam Szychulec
Adam Szychulec is Deputy CTO at InTechHouse and an electronics and embedded systems engineer with over 13 years of experience in hardware development, FPGA-based systems, embedded software, and technical leadership.
He specializes in electronic system architecture, analog and digital PCB design, FPGA and SoC development, embedded C/C++ software, and managing the complete lifecycle of complex engineering products - from early feasibility studies and technical architecture through development, testing, production introduction, and product modernization.
Adam has extensive experience leading multidisciplinary R&D teams and coordinating electronics, embedded software, mechanical engineering, testing, and project delivery. His responsibilities have included technical decision-making, project planning, risk and change management, budgeting, product testing, new product introduction, and mid-life upgrades of existing electronic systems.
His project experience includes FPGA modules for space applications, electronic systems and payloads for unmanned aerial vehicles, environmental monitoring and multispectral imaging platforms, power electronics, DC-DC converter assessment, and embedded systems developed for demanding industrial and defence-related applications.
Adam works with FPGA and SoC platforms, Xilinx Zynq, VHDL, Vivado, Altium Designer, ARM microcontrollers, embedded C/C++, Linux, digital electronics, and power electronics. He holds bachelor's and master's degrees in Electrical Engineering and is an IPC Certified Interconnect Designer. He writes about FPGA architectures, electronics design, embedded systems, hardware product development, technical risk management, UAV electronics, power electronics, and engineering leadership.
Let's talk about your next project
From first prototype to production, our engineers can help you scope it, build it and get it certified.
The FPGA Design Flow: How an FPGA Project Goes from Specification to Production
What Is a SoC FPGA? Combining CPU and Programmable Logic in One Chip (Zynq and Beyond)
Discuss your product with our R&D team
This initial conversation is focused on understanding your product, technical challenges, and constraints.
No sales pitch - just a practical discussion with experienced engineers.
Share a few details about your product and context. We’ll review the information and suggest the most appropriate next step.