Costing a Hardware, Robotics or Semiconductor Business
Your unit cost is a forecast, not a measurement, because it depends on volume you have not yet sold.
Summary
- A hardware unit costs its recurring bill of materials, labour and test, plus its share of the non-recurring engineering that created it. Then add provisions for warranty, field service, spares and obsolescence.
- Amortised development and yield are both forecasts. Amortise over a conservative volume, carry a current-yield and a mature-yield cost side by side, and track cumulative recovery against spend.
- Plan BOM cost-down rather than discovering it, cost design wins at programme level, and split R&D into product-specific, platform and exploratory work before apportioning any of it.
Most costing problems are about measuring something that already happened. Hardware has a harder version.
The two costs that decide everything are the ones that are not yet facts.
How much development spend each unit carries depends on how many units you eventually ship. And what each unit costs to make depends on a yield that improves as you learn.
Both are forecasts. Both move. And a price set on either one at the wrong point in the curve can be wrong for the life of the product.
The unit is the product plus its share of the programme
A software company can ignore development cost in because the marginal copy is free. A hardware company cannot, because the development spend is large, specific to one product, and has to come back out of the units.
So the cost object is one unit, plus its allocated share of the non-recurring engineering that created it. It has three components.
- Recurring cost per unit. BOM, assembly labour, test time, packaging, logistics. Measurable, and it falls over time.
- Non-recurring engineering, amortised. Design, prototyping, tooling, certification, qualification, firmware. Spent once, recovered across whatever volume ships.
- Provisions. Warranty, field service, spares, obsolescence.
The Founder's Guide lists which hardware costs fall in which bucket, and the general method for building a unit cost still applies. What hardware adds is that two of the three components are forecasts.
NRE amortisation is where the forecast lives
You spent ₹3.2 crore developing a product. How much does each unit carry?
The same ₹3.2 crore of development, amortised over three volumes
| Volume the NRE is spread over | NRE carried per unit |
|---|---|
| 10,000 units | ₹3,200 |
| 4,000 units | ₹8,000 |
| 1,500 units, what actually shipped in year one | ₹21,333 |
The engineering was identical. The number is wildly different, and the version you used to set your price was a guess about the future made before you had any evidence. It is the volume problem in its sharpest form: the whole fixed cost is spent before the first unit ships.
Three practical rules follow.
- Amortise over a conservative volume, not an ambitious one. If you price on the optimistic case and ship the realistic one, you have under-recovered and will discover it late.
- Separate the recovery from the margin. Report recurring cost, NRE recovery per unit, and margin as three lines. Blending them means you cannot see whether the product is working or whether the recovery assumption is.
- Track cumulative recovery against spend. A simple running number: how much of the ₹3.2 crore has actually come back. Most companies never compute it, and so never know whether a product has paid for itself.
Run the last rule on the example. Price on the 4,000-unit assumption, so each unit carries ₹8,000 of NRE, then ship 1,500 in year one. What has come back is 1,500 × ₹8,000 = ₹1.2 crore, or 37.5% of the ₹3.2 crore, with ₹2 crore still outstanding.
Yield improves, and your cost should move with it
In semiconductors it is die yield. In robotics and hardware it is first-pass test yield, assembly rework and -in failures.
The important feature is that it changes. Early production yields badly. It improves with learning, process tuning and supplier maturity, sometimes dramatically.
Which creates a real costing choice:
- Cost at current yield and your early units look terrible, which may lead you to abandon a product that would have worked.
- Cost at mature yield and your early units look better than they are, which hides a cash problem.
The workable answer: do both. Carry a current-yield cost for cash and operational decisions, and a mature-yield cost for pricing and investment decisions. Write the assumed improvement curve down and review it against actuals.
If the actual curve lags the assumed curve, that is the single most important early warning in a hardware business. Most companies see it only when the annual numbers arrive.
BOM cost-down over a lifecycle
A hardware BOM is not a fixed number. Over a product's life it falls, through component price erosion, redesign, alternate sourcing, volume breaks and integration.
Two consequences for costing.
- Your standard BOM goes stale fast. A cost built at launch and never revisited will overstate cost by the mid-life of the product, which means you will defend prices you no longer need to defend.
- Cost-down should be planned, not discovered. Set a target cost curve by quarter, with named actions against it such as a second source qualified by Q3 or a redesign removing two components by Q4. That turns cost reduction into a programme rather than a hope.
Design wins and programme economics
For anyone selling into another manufacturer, the cost object shifts again. The thing you win is not an order. It is a programme: a design-in that produces volume over several years if it goes to production.
Which means costing has to work at programme level.
- Pursuit cost. Application engineering, samples, evaluation boards, qualification support. Spent before any revenue, on programmes that may never ship. If one design-in in four reaches volume, each winner carries the cost of three losses.
- Programme contribution over its life, not margin in the first year. Early units often lose money; the programme works on the tail.
- The risk that volume never arrives. A design win where the customer's product fails in the market produces no revenue, and you have already spent the engineering. That risk belongs in the pursuit decision, not as a surprise afterwards.
On the revenue side, an OEM approval cycle is a long pipeline, which is how RevenueOS for manufacturing treats it. The costing question is what each pursuit consumes before that pipeline converts.
Provisions that get forgotten
Four, and all of them belong in unit cost.
- Warranty. A percentage of units will fail in the warranty period. That cost belongs on every unit shipped, not on the quarter in which failures happen.
- Field service. For robotics and installed equipment especially, the cost of going to site is substantial and almost never costed per unit at the point of pricing.
- Spares obligation. Holding spares for years after end-of-life is a real cost committed at the point of sale.
- Component obsolescence. A last-time buy of a discontinued component ties up cash, and some of it will be written off.
Apportioning R&D across products
This is the hardware version of the engineering apportionment problem that a SaaS business faces.
Some R&D is clearly attributable to one product: that is NRE, and it amortises. Some is platform work benefiting several products. Some is exploratory and benefits nothing yet.
Split it into those three before you apportion anything.
Product-specific NRE amortises against that product. Platform work apportions across the products using the platform, on a usage or effort basis. Exploratory R&D is investment and should sit visibly as such, not be smeared across products that did not cause it.
Companies that blend all three cannot tell whether any individual product is profitable.
Has your highest-volume product paid for itself?
Take your highest-volume product and build three numbers:
- Recurring cost per unit at current yield.
- NRE amortised at your realistic cumulative volume.
- Provisions for warranty, service and obsolescence.
Then the one most companies have never computed: cumulative NRE recovered against NRE spent.
That last number tells you whether the product has paid for itself. In our experience it is frequently a long way from where the leadership assumed it was.
Our Pricing Maturity Assessment is a short read on how your pricing, and the cost base it rests on, holds up.
Frequently asked questions
How should NRE be amortised in hardware product costing?
Over a conservative cumulative volume, not the ambitious case. Report NRE recovery per unit as its own line, separate from recurring cost and margin. Keep a running total of how much of the development spend has actually come back.
Should a hardware product be costed at current yield or mature yield?
Both. Current-yield cost is the basis for cash and operational decisions. Mature-yield cost is the basis for pricing and investment, provided the assumed improvement curve is written down and checked against actuals.
Where does warranty cost belong in hardware unit cost?
On every unit shipped, as a provision, not in the quarter when failures happen. The same applies to field service, spares held after end-of-life, and the expected write-off on last-time component buys.
How useful was this article?
One tap. It tells us what to write more of.
About the author
SRF Capital Studio
The next one
Get what we publish next, by email.
Working notes on raising, borrowing, protecting, growing and structuring capital in India. One email a week at most, and you can leave any time.
We use your address only to send this. See our privacy policy.
We store your address to send you these emails and nothing else. See our privacy policy.