Build or Buy, Properly Costed
Ask one question of every cost line: if we stop doing this, does this cost leave the business?
Summary
- In a build or buy decision only avoidable cost belongs in the comparison: the cost that leaves the business if you stop doing the work.
- Salaried staff are avoidable only if headcount actually falls. In software it almost never does, which is why build or buy analysis on absorbed cost is reliably wrong there.
- Once the avoidable cost is known, the decision turns on what the released capacity is worth. It is worth nothing if the team has nothing better to do, and a great deal if the next project on the roadmap is valuable.
- Insourcing makes the mirror-image error with less scrutiny, comparing a vendor's price with variable cost and leaving out capex, the learning curve, supervision and the capacity consumed.
A SaaS company needs document parsing in its product. Engineering estimates four months of two developers to build it. A vendor will licence it at ₹14 lakh a year.
The internal cost looks like this: two developers at ₹28 lakh loaded each, for four months. That is roughly ₹18.7 lakh of effort (2 × ₹28 lakh × 4 ÷ 12 = ₹18.67 lakh). On top, the costing model adds ₹6 lakh for infra and tooling and for a share of engineering management and office overhead. Total ₹24.7 lakh in year one.
Build looks expensive. Buy at ₹14 lakh looks obvious.
Now ask which of those costs actually leave if you don't build it.
The ₹24.7 lakh build, sorted by whether each cost leaves the business
| Cost line | ₹ lakh, year one | Leaves if you don't build? |
|---|---|---|
| Developer time (2 × ₹28 lakh × 4 ÷ 12) | 18.7 | No, unless headcount falls: both stay on payroll |
| Incremental infra and tooling | 1.2 | Yes |
| Apportioned engineering management | 4.0 | No |
| Apportioned office, HR, admin | 0.8 | No |
| Absorbed cost of building | 24.7 | What the costing model reports |
| Costs that leave if you don't build | 1.2 | Avoidable: the only build cost that belongs in the comparison |
| Costs that stay regardless | 23.5 | 18.7 + 4.0 + 0.8 |
The developers are on payroll either way. So unless you are reducing headcount, and you are not, almost none of the ₹18.7 lakh leaves.
What actually leaves is close to ₹1.2 lakh of incremental infra.
Which reframes the whole decision. You are not comparing ₹24.7 lakh against ₹14 lakh. You are comparing what else those two developers could build in four months against ₹14 lakh a year, forever.
The question that gets this right
For every cost line, ask one thing: if we stop doing this, does this cost leave the business?
If yes, it is avoidable and belongs in the comparison.
If no, it does not, and including it will push you toward buying things you should build, and outsourcing things you should keep.
The people question is where this bites hardest. Salaried staff are only avoidable if you actually reduce headcount. In a factory that means fewer operators. In a services firm it means a smaller bench. In software it almost never happens, which is why absorbed-cost build-vs-buy analysis in software is reliably wrong.
Capacity released is worth what you do with it
This is where the decision stops being arithmetic.
If you don't build, engineering time becomes free. What that is worth depends entirely on what fills it.
- If the team has nothing better to do, the capacity is worth nothing and building is nearly free.
- If the team's next best project would generate real value, the capacity is worth that value, and buying is often clearly right.
- If buying lets you avoid a hire you were about to make, it is worth that hire.
In software this is usually easier to answer than in a factory. That is because the next thing on the is known and someone has an opinion on what it is worth.
So the honest question is never "is buying cheaper than building?" It is this:
What is the best use of this capacity, and does buying free it for something better?
Most build-vs-buy analyses never ask the second half, which is why so many of them disappoint.
Avoidable and unavoidable cost, business by business
The build or buy decision in seven kinds of business, and which costs usually leave with the work
| Business | The decision | What is usually avoidable | What usually is not |
|---|---|---|---|
| SaaS | Build a feature or licence a vendor | Incremental infra, contractor cost | Salaried engineering, management |
| IT services | Deliver in-house, subcontract, or offshore | Contractor fees, travel | Bench payroll, delivery management |
| Hospitals | In-house lab or reference lab; own equipment or pay-per-use | Reagents, consumables, per-test fees | Lab space, salaried technicians |
| Diagnostics | Own collection fleet or third party | Fuel, per-pickup charges | Depot, supervisors |
| D2C | Own warehouse or 3PL | Per-order handling fees | Lease commitment, warehouse staff |
| Manufacturing | Make the component or buy it | Material, variable machine cost, direct labour if reduced | Rent, depreciation, supervision |
| Pharma | Own plant or contract manufacturing | Batch cost, QA per batch | Plant, regulatory infrastructure |
The rows differ. The method does not.
What else belongs in the comparison
Six things that are genuinely avoidable or genuinely new, and routinely left out.
- Transition cost. Migration, integration, parallel running, data transfer. Real, one-off, and almost always underestimated.
- Vendor management. Someone audits, chases, negotiates, renews, resolves incidents. Real time, rarely counted.
- Incoming verification. You will check what arrives: incoming inspection for parts, QA for outsourced code, result validation for a reference lab.
- Inventory or buffer. Buying usually means holding more to cover lead time. At a 14% cost of money, 45 extra days on a ₹300 part costs around ₹5 a unit (₹300 × 14% × 45 ÷ 365 = ₹5.18).
- Working capital timing. A vendor on 30-day terms versus weekly payroll shifts your cash position, sometimes helpfully.
- Price escalation. A vendor price today is not the price in year three. Model the renewal, especially where switching will be hard.
The things that are not costs but are still real
Write these into the decision rather than arguing about them afterwards.
- Lead time and responsiveness. In-house is available when you need it. A vendor has a queue.
- Quality control. You control your own process; you influence a vendor's.
- Dependency. A single vendor for something critical is a risk. Two cost more. Neither is free, and the choice should be deliberate rather than discovered during an outage.
- Capability loss. Once you stop doing something, the people who knew how leave or forget. Bringing it back is far more expensive than keeping it was. For anything core to what you sell, this should weigh heavily, and in software it is the argument that most often decides it.
The reverse decision gets far less scrutiny
Insourcing, bringing in something you currently buy, is usually assessed less rigorously and carries more risk.
The error is the mirror image. You compare the vendor's price to your variable cost, ignore the capex, the learning curve, the extra supervision and the capacity consumed, and conclude it is obviously cheaper.
Three questions before any insourcing decision:
- What capacity does this consume, and what is that capacity currently earning? If it displaces something higher-value, you have made yourself worse off.
- What is the investment, and over what volume does it recover? At today's volume, not the volume you hope for.
- How long until you match the vendor's quality? There is always a learning curve and it is always longer than planned.
Seven steps to a build or buy decision you can defend
- List every cost of doing it in-house, starting from what one unit of the work costs.
- Mark each avoidable or not. Be honest about people.
- Total the avoidable column. That is your real cost of doing it yourself.
- Build the full buy cost. Vendor price, transition, verification, vendor management, extra holding, escalation.
- Compare those two.
- Then the capacity question. What fills the released time, and what is that worth?
- Finally the non-cost factors, written down, and whether any changes the answer.
Seven steps, one afternoon, and a decision you can defend.
The test on your last build-or-buy decision: was it made on absorbed cost or avoidable cost? If you cannot tell, it was almost certainly absorbed, and the answer may have been wrong in a direction that is still costing you.
Our Pricing Maturity Assessment gives you a short read across your pricing and the cost floor underneath it, including whether your cost figures separate what leaves from what stays.
Frequently asked questions
What is avoidable cost in a build or buy decision?
The cost that leaves the business if you stop doing the work: contractor fees, incremental infrastructure, materials, per-unit charges. Salaries count only if headcount actually falls. Apportioned such as management, office and HR almost never leave, so they do not belong in the comparison.
Why does an absorbed-cost comparison favour buying?
Because absorbed cost loads the in-house option with overhead and salaried time that stays whichever way the decision goes. In the example above that is ₹23.5 lakh of a ₹24.7 lakh build. That makes a ₹14 lakh licence look cheap when the avoidable cost of building is ₹1.2 lakh.
What is the most common mistake when insourcing?
Comparing the vendor's price with your variable cost alone. That leaves out the capital investment, the learning curve, extra supervision and the capacity the work will consume. Test the recovery of any investment at today's volume, not at the volume you hope for.
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.
Related reading
