TL;DR: Build or buy splits along five axes: strategic importance, skill availability, time horizon, regulatory profile and cost sensitivity. Score the role on each, and where four point the same way the cost model only confirms what you already know. When you do run the numbers, label every input as a published figure or as an assumption, because most of the inputs are assumptions and they are where two teams reach different answers from the same data.
Build versus buy started as an architecture question and applies just as well to hiring. This is the financial companion to when to use IT staffing versus in-house hiring, which covers the same decision from the operational side.
What decides build or buy?
Five axes, and the first four matter more than the fifth.
Strategic importance. Does the seat shape architecture or product direction over years? Core means build, whatever the rate comparison says.
Skill availability. Can you hire it locally in a reasonable window? A search that has already failed twice is telling you the pool is not there.
Time horizon. One phase, or indefinitely? Buying a permanent function converts a salary into a rate premium that compounds every year it continues.
Regulatory profile. Does the work sit inside a supervised boundary? That does not rule out buying, but it adds contract obligations you should price in rather than discover.
Cost sensitivity. Is runway or margin the binding constraint? This is the weakest axis to decide on alone, and the one most often used that way.
Score the role on all five. Where four point the same direction, the decision is made and the cost model is a confirmation exercise.
Skill availability deserves a note, because it is the axis teams most often assess from memory. The US Bureau of Labor Statistics projects data scientist employment to grow 35 percent between 2025 and 2035 and information security analysts 21 percent, against roughly 4 percent across all occupations. For those seats, a local search failing is the expected outcome rather than a recruiting failure worth fixing.
Where each cost input comes from
A build-versus-buy model has three kinds of number in it, and only one is published. Knowing which is which is what makes the model defensible.
Published salary medians. The US Bureau of Labor Statistics puts the May 2024 median annual wage at $135,980 for software developers, $129,180 for information security analysts and $120,230 for data scientists. Salary only, before employer taxes and benefits.
Published provider rates. The developer rate cards give senior international client rates by role and market. Already loaded, which is why they are not comparable to a raw salary.
Everything else is an assumption. The loading multiplier, recruiting cost, ramp cost and management overhead are all your own numbers. They are not published anywhere, and any model that presents them as sourced is misrepresenting them.
Apply ramp cost to both sides. Teams routinely charge the ramp against the bought engineer and forget the in-house hire has one too, usually a longer one because they also learn the company. Charging it to one side and not the other is the most common way this model gets accidentally rigged.
Building the comparison
Start from the published median for the role, apply your loading multiplier, and write the multiplier down. Then add recruiting cost, ramp cost and management overhead as your own named assumptions.
On the buy side, take the published rate, decide a utilisation assumption and state it, then add your own management overhead and tooling. The buy side has fewer lines because vetting, HR administration and employer obligations sit with the provider, and that difference is the point rather than an accounting convenience.
Include recruiting cost honestly on both sides. A bought seat still costs you interview time. A built seat costs an agency fee or a recruiter’s loaded hours across the search, and that line varies more between companies than any other in the model.
A worked comparison
The arithmetic below is illustrative rather than a client engagement. Substitute your own inputs and re-run it.
Build. A senior software developer at the BLS median of $135,980, with a stated 1.3 loading multiplier for employer taxes, benefits, equipment and tooling, comes to roughly $173,000.
Buy. A senior backend developer at the published Vietnam rate of $47.50 per hour, at an assumed 160 hours a month, comes to about $91,200. Add roughly $12,000 for your own management overhead and tooling, and the engagement costs about $103,000.
Difference. Around $70,000 in year one, before recruiting cost on either side and before any velocity effect on either side.
That is a smaller number than this category usually quotes, and it survives a finance review. Second Talent clients save $103,000 or more per hire against a comparable Western salary, and the gap between those two figures is mostly seniority and market rather than method.
Patterns that settle it without the model
Some roles decide themselves, and running a spreadsheet on them is a way of postponing a decision you have already made.
Build wins when the seat sets technical direction over years, when the value comes from institutional context that accrues slowly, when the role develops other engineers so tenure is the point, when you already have a pipeline producing candidates, or when secrecy makes a third party in the chain unwelcome.
Buy wins when the work has a defined shape and end, when local supply has failed you twice, when runway or a delivery date rules out a three-month search, when you are hiring across a border without a legal entity, or when you want a trial before committing.
Where a pattern applies, run the model anyway and then stop arguing about it. The number is useful as documentation even when it changes nothing.
The compliance line in a buy decision
Buying across a border moves employment obligations, and where they land depends on the structure rather than on the label.
The IRS common-law test weighs behavioural control, financial control and the type of relationship. The HMRC CEST tool asks the same question in UK terms. A contractor you engage directly, working your hours on your systems under your direction, often fails both.
A provider employing through a licensed local entity moves that exposure. A broker introducing a freelancer does not, whatever the pitch implied. Confirm which you are buying, because the cost model changes considerably if back taxes are a live possibility. Our guide to worker classification in cross-border IT staffing covers it.
Most teams end up doing both
The hybrid is the normal end state rather than a compromise. What matters is whether the split is deliberate or accumulated.
Decide the split by work type. Core product and architecture built in house, phase-shaped and specialty work bought. Write down which is which before anyone is hired.
Keep one register. Every seat, which side it sits on, who directs it, the notice period and the renewal date.
Review the boundary quarterly. A bought seat renewed three times for the same work has become a permanent function, and the premium is compounding against you.
Move seats deliberately. Agree the conversion fee and trigger at the start, not at the point you have decided you want to keep someone.
What the model cannot price
Three things move a build-versus-buy decision and resist being put in a spreadsheet. Naming them beats pretending a number covers them.
Option value. A bought seat can end on notice. A built seat cannot, or not without severance and a difficult conversation. That flexibility is worth something real when your roadmap is uncertain, and any figure you assign to it is invented.
Where knowledge settles. Work directed by your manager, reviewed by your team and documented in your systems leaves knowledge with you. The same work handed over as an outcome does not. That difference compounds and does not appear in year one.
Team effects. A senior engineer who raises the standard around them is worth more than their output, and one who does not integrate costs more than their rate. Neither shows up in a cost comparison, and both are visible within a quarter.
Present these alongside the model rather than inside it. A reviewer who sees them listed as unpriced factors trusts the priced ones more.
Revisiting the decision
Build versus buy is a decision with a shelf life, and most teams make it once and never look again.
Three things should trigger a re-examination. A bought seat renewed for the third time on the same work, which means it became permanent while nobody was watching. A local search that succeeds where two previous ones failed, which means the supply picture changed. And a shift in what the seat does, since a role that grows into architecture ownership has moved axis.
Put the review on the same quarterly cadence as the budget rather than treating it as a special exercise. It takes twenty minutes when the register is current and a week when it is not.
Build vs buy FAQs
What share of engineering should be bought?
There is no defensible benchmark for this, and figures in circulation are usually someone’s sales pitch. The right share falls out of how much of your roadmap is phase-shaped, which is a fact about your company rather than about the industry.
Does buying hurt in-house capability?
It can, if you buy the work that would have taught your team something. Buy phase-shaped and specialty work, keep the work that builds institutional knowledge, and require documentation as a deliverable either way.
How long before a bought seat should be built?
When it stops being phase-shaped. Three renewals for the same work is the practical signal, and by then the premium has usually exceeded a recruiting fee.
What if the model says buy and the team says build?
Check whether the disagreement is really about strategic importance, which is the axis that should override cost. If it is about preference rather than importance, the model wins. If it is about importance, the model was answering the wrong question.
Takeaways
- Score five axes first. Where four agree, the model only confirms it.
- Only salary medians and provider rates are published. Everything else is your assumption.
- Apply ramp cost to both sides, or the model is quietly rigged.
- Confirm who employs a bought engineer before trusting the cost comparison.
- Three renewals for the same work means the seat became permanent. Revisit it.
Run the numbers with published rates
Second Talent publishes rates by role and market, so the buy side of your model can cite something a reviewer can open.
Open the rate cards, tell us which seat you need to fill, or use the ROI guide to hold the number up after twelve months.
Hiring contractors rather than employees changes the arithmetic. The freelance developer rate index prices 14 roles across nine regions, benchmarked against North America and sourced from published wage data.
