"We'll just hire engineers" sounds cheaper than working with a partner. On the surface the maths is simple: a contractor or agency rate looks higher per hour than a salaried developer's hourly equivalent, so in-house wins. Then you add up everything a salary line doesn't show, and the picture changes, which is part of why the IT and software outsourcing market sits around $613 billion in 2025. The right comparison isn't rate vs salary. It's the fully-loaded, risk-adjusted cost of each option for the work you actually have.
The salary is the tip of the iceberg
A fully-loaded in-house engineer costs far more than their salary line:
- Recruiting: weeks of leadership time, plus agency fees, before anyone writes a line of code.
- Ramp-up: months before a new hire is fully productive, and you pay full salary the whole time.
- Benefits, equipment, overhead: routinely 1.25–1.4× base salary once you add taxes, insurance, tooling and management time.
- Bad-hire risk: the US Department of Labor puts the cost of replacing a bad hire at *at least* 30% of first-year salary; SHRM's range runs from 50% up to 200%. Hiring is a probabilistic bet, and the downside is steep.
- Bench risk: when the backlog dips, you still pay full-time salaries. Demand for engineering work is rarely as smooth as a payroll commitment assumes.
Put those together and a "$120k engineer" is closer to a $170k–$200k annual commitment before you account for the risk that the hire doesn't work out or the work dries up.
A quick worked comparison
Say you need to ship one defined product over four months. In-house, you'd recruit (1–2 months, often unsuccessful on the first try), onboard (another month of reduced output), and carry the role afterward whether or not the next project is ready. A partner can put a proven, senior team on it next week, deliver in the window, and stop billing when it's done. Even at a higher hourly rate, the partner can be cheaper for that shape of work, because you're not paying for recruiting, ramp, or the bench afterward. Flip the scenario to a permanent, core product that needs constant evolution, and the in-house economics improve every year the role stays full.
When in-house wins
- Core, long-horizon product work that is your business and that you must own permanently.
- Deep domain knowledge you need to retain in-house rather than rent.
- Stable, predictable demand that keeps a team busy for years, so ramp-up cost is amortised and there's no bench.
When a partner wins
- You need to move now: a partner can shortlist in days, not the months hiring takes.
- Variable or project-based demand, where you scale up and down without layoffs or idle salaries.
- Skills you need once (AI, security, a specific platform) without a permanent headcount bet on a niche skill.
- You want someone who has already shipped at your scale to carry the delivery risk rather than learning on your time.
The honest answer: usually both
The strongest setup we see is a lean in-house core for product ownership, plus a flexible partner for surge capacity and specialist skills. You keep the knowledge that matters (product direction, domain context, the institutional memory of why things are built the way they are) and buy speed and depth where you need them. The in-house core also makes the partner relationship better: there's always someone internal who owns the outcome and can direct the work, which is exactly the continuity a dedicated-team model provides. If your current setup is straining under that split, it's worth checking the signs you've outgrown your dev agency before defaulting to a bigger in-house build. See our engagement models and pricing for how we structure that flexibility.
A quick way to decide
Sort the work you have into two buckets and the answer usually falls out:
- Permanent, core, always-on? That's a hire. The ramp-up cost pays back over years and you want the knowledge to live in-house.
- Time-boxed, specialist, or spiky? That's a partner. You avoid the recruiting delay, the bench risk, and the bad-hire downside, and you get senior people who've done it before.
Most companies have both kinds of work at once, which is why "in-house or partner" is usually the wrong framing. The real question is which slices of your roadmap belong in which bucket, and revisiting that split as demand changes, rather than defaulting to headcount because it feels more permanent.
A common mistake
The trap is hiring for a temporary spike. A burst of project work tempts a company into a permanent role; six months later the spike is gone but the salary isn't, and now there's pressure to invent work to justify the seat. The opposite mistake is just as costly: leaning on a partner indefinitely for work that has clearly become permanent and core, paying a rate premium year after year for capability you should have brought in-house once demand stabilised. Renting capacity for temporary demand and owning it for permanent demand keeps the cost structure honest, and the test is simply whether the work has settled into something steady and central enough to justify a salary, recruiting cost and all.
Compare fully-loaded cost to fully-loaded cost. Salary-vs-rate is not the real comparison.
Weighing the two for a specific role or project? Give us the details and we'll lay out a candid build-vs-partner comparison, headcount math included, and we'll say so if hiring is genuinely the better call.