In-house team vs Outsourced development

Any comparison that reaches for figures here is guessing, because salaries, rates and employer costs vary by market, seniority and specialism, and they change. What is stable is the structure of the two commitments, and that is what should decide it.

An in-house engineer is a fixed cost that continues regardless of what the roadmap needs this quarter. The salary is the visible part, and it is not the whole part. Employer contributions and benefits sit on top of it. Recruitment carries a cost whether you use an agency or absorb the time internally. Equipment, software licences and tooling are per person. Management, review and career development are real time taken from someone senior. Vacancies cost you delivery for every month they stay open, and departures cost you the recruitment again plus the context that left. None of that is an argument against employing engineers. It is an argument for comparing the total cost of the arrangement rather than the salary line, because the salary line understates it consistently and in one direction.

An outsourced engineer is a variable cost with a higher headline rate, and the rate is higher for reasons that are not all margin. It carries recruitment, the risk of paying someone between engagements, management, tooling, holiday and sick cover, and the supplier’s own overhead. What you are actually buying with the difference is the removal of the fixed commitment and the removal of the hiring cycle. Whether that is worth paying for depends on how confident you are that the work continues, and confidence is the correct word: many organisations are more certain of their roadmap in the plan than the following year justifies.

The comparison people get wrong is treating an unfilled vacancy as free. An approved role that has been open for months costs the delivery it would have produced, and it usually costs it silently, appearing as a plan that keeps slipping rather than as a line anyone reviews. When you compare a rate against a salary, compare the rate against the salary plus the true employer cost plus the expected time to fill the role plus the probability that it is not filled at all. That comparison is harder and much more useful, and it sometimes concludes firmly in favour of hiring, which is the point of doing it honestly.

One more structural point that is easy to miss. Fixed costs and variable costs behave differently under uncertainty, not just on average. If the funding is committed for a year rather than forever, if the demand is seasonal, or if the programme could be cancelled by a decision above you, then a commitment you can adjust is worth more than a lower unit cost you cannot. If the work is certain and permanent, the reverse is true and the fixed commitment is the cheaper way to buy it.

If there is one factor that separates good outcomes from bad in both models, it is continuity of the people. Not the employment status, the continuity. An engineer who has been on your system for a year is dramatically more effective on it than a comparably skilled engineer who arrived last month, and that gap is mostly context: knowing why a decision that looks wrong was correct at the time, which integration misreports its own behaviour, which part of the schema everybody is careful around, and what the business actually means by the word it uses for a customer.

In-house employment is the arrangement most likely to produce that continuity, and that is its strongest structural advantage. It is not a guarantee. A permanent team with high attrition loses context just as thoroughly as a rotating supplier does, and a lot of organisations that believe they have accumulated knowledge in fact have one person holding it while everyone else works around them. If your retention is poor, the main advantage of hiring in-house is not actually operating, and the honest comparison is closer than the strategy assumes.

Outsourcing loses knowledge by default and keeps it only when the arrangement is designed to. The controls are unglamorous and they work. Insist on named individuals rather than roles, so a substitution is visible instead of silent. Require an interview and a paid overlap before any change of person. Keep the work in your repositories and your review process so your own engineers see the code as it is written rather than at handover. Have documentation and architecture decisions written as the work happens instead of promised for the end. Refuse to let any system become the private property of one engineer, external or internal, and treat it as a defect when it happens.

The test we would apply, whichever model you choose, is this: if the person or the team who knows the most about a system stopped tomorrow, what would happen. If the answer is that delivery halts for a month, then the knowledge is concentrated in a way that has nothing to do with employment status and everything to do with practice. Fixing that is worth more than the in-house versus outsourced decision on its own.

There is a related trap on the outsourcing side worth naming explicitly. An arrangement that produces working software while leaving nobody internally able to explain how it works is a dependency, not a supply of capacity. That is a failure of the arrangement rather than an inevitable property of contracting, and the way to avoid it is to require, from the first week, that you could end the engagement with notice and be left with a running system your own people can operate. If that is not true at every point, the engagement has a problem regardless of how the delivery looks.

The time difference between the two models is larger than most plans allow for, and it is the factor most often underestimated in board papers. Approving a headcount is not the start of capability. The sequence is writing the role, sourcing candidates, screening, interviewing, deciding, negotiating, an offer, a notice period that is frequently months for senior people, then onboarding. Any one of those steps can restart the whole thing when a preferred candidate declines. For senior and specialist roles, the honest estimate from approval to productive work is measured in months, and that is when the process goes well.

Contracted capacity removes the search and the notice period, because those already happened. What remains is scoping, agreeing terms, arranging access and onboarding. The constraint moves from the market having the right person to the supplier having them, which is a smaller and faster constraint but not a nonexistent one. A supplier who says yes to every specialism immediately is describing a sales timeline, and the reasonable answer to a request for an unusual skill set is sometimes that it will take a few weeks to introduce the right person.

Access is the step that is consistently underestimated on the outsourced side, and it is usually the client who is the bottleneck rather than the supplier. Accounts have to be raised, permissions approved, security reviews completed, devices agreed and environments made to work for someone who has never run the codebase. Where this is prepared before the start date it takes days. Where it is discovered in week one, it can absorb most of the first fortnight, which is expensive and entirely avoidable.

Productivity is a separate question from starting, in both models, and it depends far more on the state of what people are joining than on their employment status. A clean codebase with tests, documentation and a working deployment pipeline is fast to join for anybody. A large system with no tests, tribal knowledge and a manual release process is slow to join for anybody, including the excellent engineer you just hired permanently. If you want new capacity to be productive quickly, the highest-value preparation is usually improving the thing being joined rather than choosing between the two models.

Control is the argument most often made for building in-house, and it is frequently made imprecisely. Employment does give you a simpler and more direct set of controls: your vetting, your devices, your policies, your access model, an audit trail your own auditors already understand, and the ability to change what someone is working on this afternoon without a commercial conversation. Those are genuine and they should be weighed.

What employment does not automatically give you is quality, security practice or delivery discipline. An in-house team with no code review, no test coverage and a manual deployment process is not more controlled than an external team working through your pull request process into your CI. It only feels that way because the people are yours. The controls that actually protect you, least privilege access, review before merge, automated checks, audit logging and a defined process for granting and revoking access, are model-independent, and they are the ones worth being strict about.

External access does have to be designed rather than assumed. The workable position is that supplier engineers exist as named individuals in your identity provider, with permissions granted through your own access controls and revoked through your normal leaver process the day someone rolls off. Work happens in your repositories, your cloud accounts and your CI, so there is no supplier environment to be released later. Where personal data is involved, the arrangement should be documented properly under UK GDPR, including which party is controller and which is processor, where processing happens and what the engineers may see. Where there are constraints on production data, on device management or on the location of the people, those belong in scoping rather than in a surprise during delivery.

Some environments make external access genuinely hard, and it is worth distinguishing those from environments where it is merely unfamiliar. If a regulator, a contract or a customer requires specific personnel vetting, specific processing locations or restrictions that no external arrangement can satisfy, then the constraint decides the model and no engineering argument moves it. That is a legitimate reason to build in-house and we would tell you so directly. But a great deal of what gets described as a security objection is habit rather than requirement, and the way to tell the difference is to write down the actual rule and check whether an external team could satisfy it. Often they can, with an arrangement that costs some setup effort and then works.

One control question deserves an unambiguous answer. Intellectual property in contracted work should be assigned to you on creation rather than on final payment, and the supplier’s own engineers should be under agreements that make that assignment real rather than nominal. If a supplier cannot show you that chain when your counsel, an investor or an acquirer asks, that is a reason to be concerned about the supplier, not about outsourcing as a model.

Framing this as a binary makes the page cleaner and the decision worse. In practice, most organisations that build software of any size run a mixture, and the ones that do it well have decided the split deliberately rather than accumulating it by accident.

The split that tends to work divides the work by permanence and by proximity to the domain. Permanent staff hold the parts of the system where the business logic lives, where the decisions are frequent and consequential, and where the accumulated understanding is the point. External capacity carries work that is bounded, specialist, temporary or peripheral to the domain: a migration with an end date, a mobile client, an infrastructure and delivery layer, a data pipeline, a period of extra throughput on a funded programme. The principle is simple to state and harder to hold: do not contract out the part of the system you most need to understand.

The version that fails is the mirror image, and it is common enough to be worth warning about. An organisation outsources the core product because it is the largest piece of work, keeps a small internal group for coordination, and discovers a year later that nobody employed by the company can explain how the thing works or estimate a change to it. At that point the supplier relationship has stopped being a choice, which is bad for the client and, over time, bad for the supplier too, because engagements held together by dependency rather than value are the ones that end badly.

There is also a good version of the transitional hybrid, where external capacity is explicitly there to be replaced. You run a team to keep delivery moving while recruitment proceeds, and the arrangement is designed from the first week to hand over: the same repositories, the same review process, documentation written as the work happens, and permanent joiners paired with the people who built it. This works well and we take engagements shaped that way. The condition is that it is written down as the plan rather than left as an intention, because an intention to insource with no date, no owner and no budget is how a temporary arrangement quietly becomes a permanent one.

A practical way to run the mixture is to be explicit, per system rather than per person, about who owns it. Every significant part of the platform should have a named internal owner accountable for it, even when the work on it is being done externally. That single discipline does more to prevent the dependency failure than any contractual clause, because it forces someone internal to understand the system well enough to accept the work.

Very few organisations decide this once and hold it. Budgets change, a programme ends, hiring finally succeeds or finally fails, and the model has to change with a system already running and a team already in place. This is the messy part, and it is worth planning even if you do not expect to need it.

Moving work from an external team to an in-house one is an insourcing programme, and it should be resourced as one rather than treated as an administrative change. The sequence that works is to hire first and overlap deliberately: permanent engineers join while the external team is still delivering, pair on real work rather than sitting through walkthroughs, take ownership of one system at a time with the previous owners still available, and only then reduce the external capacity. The failure mode is ending the contract on the day the new hires start, which converts every question into an archaeology exercise and reliably costs more than the overlap would have. Expect the transfer to take longer for systems with poor documentation and no tests, because in those the knowledge really is in people rather than in the codebase.

Moving from an in-house team to external capacity is usually less about knowledge transfer and more about arrangement design. The important decisions are which systems the external team will own, who internally remains accountable for each of them, how work will be visible weekly, and what the exit position is at every point rather than only at the end. Where this follows a reduction in the permanent team, be honest about sequencing: knowledge should transfer while the people who hold it are still employed and still motivated to transfer it, which means the handover happens before the departures, not after.

In both directions, keep the artefacts in your control throughout so the switch is a change of who works, not a change of where things live. Repositories, cloud accounts, CI, issue tracker and documentation should be yours in every model, so that changing the model means people start or stop rather than something having to be untangled and moved. If a supplier holds any of that, resolve it before you need to switch rather than during.

Finally, an honest note about why these switches often happen. A large share of insourcing decisions follow an outsourcing arrangement that was never designed properly: work done at arm’s length, no internal owner, no visibility between status reports, and knowledge that never came back. Before concluding that outsourcing failed, it is worth checking whether it was the model or the arrangement. Equally, before concluding that hiring failed, check whether the roles were genuinely fillable at the level and salary offered. Both decisions get made in frustration more often than they get made on evidence, and the frustrated version is expensive in both directions.