Build or buy a test bench: the real cost of an in-house bench

The bench was supposed to take six weeks. The purchase order for the instruments was signed in January, the cabinet was wired by March, and in June the test engineer who built it was still the only person who could run it. When he moved to another project, the bench stopped. The parts had cost exactly what the budget said. Everything else had not been in the budget at all.

This is the usual shape of the build-or-buy question. The bill of materials is visible, easy to quote and easy to compare. The hours, the risk and the years of maintenance are not. This article does not argue that buying is always right; many teams build excellent benches. It gives a method to put every cost item on the table before deciding, so the decision is made on the full cost and not on the part of it that fits in a purchase request.

All figures in this article are placeholders for your own data. We deliberately give no prices or hours: they depend too much on the bench, the team and the country. What transfers from one project to another is the structure of the calculation.

1. The cost model in one line

The total cost of ownership of a bench over its useful life can be written as:

TCO = C_eng + C_hw + C_sw + C_cal + C_maint + C_doc + C_opp + C_risk

Each term is explained below. The trap is to compare a supplier quote, which already includes most of these terms, against an internal estimate that includes only C_hw.

1.1 Principle diagram (described)

Picture a timeline from left to right: specification, design, procurement, build, debug, qualification, production use, and end of life. Above the line, put the one-off costs (engineering, components, licences purchased once, documentation). Below the line, put the recurring costs (licence renewals, calibration every period, maintenance, operator time, spares). Then shade the area where the bench is not yet usable: that shaded area is where opportunity cost accumulates. Most internal estimates only look at the “procurement” box above the line.

2. The cost items, one by one

2.1 Engineering hours (C_eng)

This is usually the largest term and the most underestimated. List the activities, not just “design”:

• requirements and test specification (what the bench must measure, with what accuracy, at what throughput);
• electrical design: schematics, signal conditioning, protection, power distribution, grounding;
• mechanical design: cabinet, fixtures, connectors, cable management, safety guards;
• harness and wiring design, including the breakout or interface panel;
• software: drivers, test sequences, operator interface, reporting, database;
• debug and integration, which is where schedule slips live;
• bench qualification (FAT/SAT equivalent, even if internal);
• training and handover.

Use a loaded hourly rate (salary plus overheads), not a salary rate. And count the hours of the people who review, approve and support, not only the builder.

2.2 Components and hardware (C_hw)

Instruments, I/O boards, power supplies, electronic loads, relays and switching matrices, connectors, cabinet, cables, fixtures. Add three items that are often forgotten:

• spares for wear parts (connectors and contact probes in particular);
• iterations: the second batch of parts ordered after the first prototype showed a mistake;
• lead time effects: an instrument on long lead time may force a design change or an expensive alternative.

2.3 Software licences (C_sw)

Development environments, test sequencers, runtime licences per station, real-time targets, analysis tools, version control and database tools. Separate:

• one-off purchases from annual subscriptions or maintenance;
• development licences from deployment licences (one per bench, often);
• the cost of staying current: a tool version change can force a migration of the test code.

The guide on moving from scripts to a test sequencer discusses the software architecture choices behind this term.

2.4 Calibration and metrology (C_cal)

Any bench used to accept or reject a product must have traceable measurements. That means a calibration interval for each measuring instrument, ideally by a laboratory working to ISO/IEC 17025, plus the downtime while instruments are away, plus periodic verification of the whole measuring chain (not only the instrument, but the switching, cables and fixtures). If the bench is used for production decisions, add a measurement system analysis such as gauge R&R.

2.5 Maintenance (C_maint)

Connector and probe replacement, relay wear, firmware and OS updates, PC replacement, obsolescence of I/O boards, and the hours of the person who knows the bench. A useful exercise is to estimate the bus factor: how many people need to leave before the bench cannot be repaired? If the answer is one, part of C_risk belongs here.

2.6 Documentation (C_doc)

Schematics as built, harness drawings, wiring lists, software architecture, user manual, maintenance procedure, calibration records, qualification report. Documentation is cheap when written during the build and very expensive when reconstructed a year later from the cabinet itself.

2.7 Opportunity cost (C_opp)

Opportunity cost is what the team did not do while building the bench. Two parts:

• the engineering work displaced: your test or design engineers are building tooling instead of developing or validating the product;
• the delay: every week the bench is not ready, the product tests it was meant to run are not running.

This term does not appear on any invoice, which is why it is skipped. It is also often the largest.

2.8 Risk (C_risk)

Risk is expressed as probability × impact, summed over the main scenarios:

• the bench does not reach the required accuracy or throughput and needs a redesign;
• the schedule slips and a product milestone slips with it;
• a bench defect causes a wrong pass or a wrong fail (false acceptance is the costly one);
• the builder leaves and the bench becomes unmaintainable;
• a safety incident on a high-voltage or high-current bench.

3. Worked method: comparing two options

Example (method only; symbols replace values, which must come from your own data).

Let H be the internal engineering hours, r the loaded hourly rate, and T the delay (in weeks) before the bench is usable.

Internal build:
C_eng = H × r
C_opp ≈ T_int × v, where v is the value of one week of the product programme (cost of the team waiting, or margin lost from a later start of production)

Purchased bench:
C_eng = H_spec × r (writing the specification, reviews, acceptance, typically much smaller than H)
C_opp ≈ T_ext × v

The difference in opportunity cost is (T_int − T_ext) × v. If the internal build takes longer than the supplier lead time, this term grows linearly with each week, independently of any part price.

For risk, take each scenario i with probability p_i and impact I_i:

C_risk = Σ p_i × I_i

A simple illustration of the arithmetic: if one scenario has a probability of 0.2 and an impact equal to 10 weeks of programme delay, its expected cost is 0.2 × 10 × v = 2 × v, the same as two certain weeks of delay. Writing it this way makes risk comparable with the other terms instead of leaving it as a vague worry.

Decision rule: compute TCO for both options over the same horizon (the useful life of the bench), with the same assumptions on use, calibration and maintenance. If the two are close, the deciding factors are usually strategic: is test know-how a core competence you want to own, and do you have the people to maintain the bench for its whole life?

4. When building in-house makes sense

Building is often the right choice when:

• the bench is simple, low-channel, and close to work the team does every day;
• the test method is itself a competitive secret;
• the team has spare capacity and test-system skills that would otherwise be idle;
• the bench is a one-off for a short investigation, not a production or acceptance tool;
• the team commits to the documentation and maintenance terms above, not only to the build.

5. When buying (or outsourcing) makes sense

Buying a bench, or having it built to your specification, is often the better choice when:

• the bench must be qualified and traceable because it is used to accept products (see ATP vs QTP), which an in-house build can achieve only with the same documentation and calibration discipline;
• the schedule is tight and the opportunity cost per week is high;
• the bench combines several disciplines (real-time simulation, power, harnessing, software) that no single internal person covers;
• several identical benches are needed, so documentation and repeatability matter;
• the internal team should stay focused on the product.

A middle path is common: buy the core (a HIL bench or a compact Mini HIL test bench, interface hardware such as breakout boxes) and keep the test sequences and product-specific know-how in-house.

6. Common mistakes

• Comparing a supplier quote with a parts list. The quote includes engineering, documentation and qualification; the parts list does not.
• Counting the builder’s hours at zero because “he was already on the payroll”.
• Forgetting recurring costs: licence renewals, calibration and maintenance over the bench’s whole life.
• Skipping bench qualification. An unqualified bench is a risk generator. The FAT and SAT guide describes what qualifying a bench involves.
• No owner after delivery. A bench without an owner degrades quietly until a test result is wrong.
• Underestimating the harness and interface. Connectors, wiring and fixtures take a large share of build and debug time; see the guide on harness continuity and insulation testing.

7. Checklist: before deciding build or buy

• [ ] Written bench specification: channels, accuracy, throughput, safety, life.
• [ ] Engineering hours listed per activity, at a loaded rate.
• [ ] Parts list with spares, iterations and lead times.
• [ ] Licences split into one-off, annual, development and deployment.
• [ ] Calibration intervals, traceability and downtime estimated.
• [ ] Maintenance plan, obsolescence and named owner.
• [ ] Documentation deliverables listed and budgeted.
• [ ] Opportunity cost per week of delay estimated with the programme manager.
• [ ] Risk scenarios listed with probability and impact.
• [ ] Both options compared over the same horizon and assumptions.

8. Conclusion

An in-house bench is rarely cheap or expensive on its own. It is cheap or expensive compared with what it displaces and what it risks. Put every term of the cost model on paper, including the ones that will never appear on an invoice, and the decision usually becomes obvious. For a general framework, the concept of total cost of ownership is a good reference.

Weighing an in-house bench against a custom one? Request a quote from RAYNOV with your specification, and you will have a like-for-like basis for your comparison.