"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 — 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.
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.