TL;DR: Compare build and buy over the same useful lifetime, including engineering effort, operating costs and exit. Use finance-approved loaded rates and distinguish incremental cash from opportunity cost. There is no universal crossover year; workload growth, vendor terms and the value of owning the capability decide it.
How to approach it
Reframe from "what does it cost to acquire" to "what does it cost to own". The missing line items are always people-time during initial build, permanent operational burden, and the eventual migration cost when either choice is replaced.
A strong answer
Price the engineers honestly. Ask finance for a loaded monthly or hourly rate that includes the agreed benefits and overhead. Keep the units consistent. Two engineers for three months consume six engineer-months, or half an engineer-year. With an illustrative loaded rate of ₹3 lakh per engineer-month, that is ₹18 lakh of allocated effort before infrastructure or ongoing support. It may not all be new cash spending if the engineers are already employed, but it still uses capacity that could deliver other work.
Estimate ongoing ownership separately.
| Cost line | Build | Buy |
|---|---|---|
| Initial delivery | Engineering months, fully loaded | Licence + integration engineering |
| Ongoing operation | On-call, patching, scaling work | Vendor fee, version upgrades, support liaison |
| Change requests | Roadmap you control | Vendor roadmap you influence |
| Exit | Migration of data and integrations | Same, plus contract terms |
The build column's operating line is systematically underestimated because maintenance hides inside "the team's normal work". A self-built scheduler needs ongoing operational ownership while it remains in service. A purchased one can transfer some maintenance to the vendor but still needs integration, access control and incident ownership internally. That visibility asymmetry, not technology, drives most bad decisions in both directions.
Weight by strategic value. The deciding question: would doing this capability distinctly better differentiate the product? Build what differentiates; buy commodity plumbing. A standard CI service is often a buy candidate, while unusual security, scale or hardware requirements can justify internal work. A core matching engine may favor ownership, but compare vendor capability and time-to-market rather than treating the label “core” as the answer.
Run both columns over the expected useful lifetime, including a realistic mid-life change request ("we now need multi-region"), because vendors charge for scope changes and builds absorb them invisibly into roadmap delays. Add the exit cost for each: data export formats, integration rewiring, retraining. Show scenarios for demand, maintenance staffing and vendor pricing. Either option can win early or late; report the crossover only if the model produces one, and include delivery timing and reliability requirements in the decision.
What interviewers probe next
"How do you prevent double-counting?" Present two views: incremental cash expenditure and the full resource/opportunity-cost comparison. Existing staff may add no payroll cash, but their effort is not free. Do not add the same salary again as a separate overhead line, or mechanically add speculative lost revenue to loaded labor; show the foregone alternative and use a consistent valuation method agreed with finance.
"Does not this favour buying everything?" Only if you ignore lock-in risk and the compounding value of owned expertise. Name the reversal condition: high differentiation value or unusual scale tips back toward build despite higher visible cost.
"Who owns the decision?" Engineering presents the full-cost model; product owns the strategic weighting; finance validates the loaded-rate assumptions. Decisions made by any one alone predictably skew.
Common mistakes
Comparing a vendor fee with a zero-cost internal build while leaving engineering effort and maintenance outside the model.
Assuming vendor prices stay flat through renewals. Model contractual renewal terms and sensitivity scenarios; do not assume an unsupported market-wide uplift.
Forgetting integration is bidirectional: bought tools still consume engineering time to connect, monitor and upgrade.