In-house developers, a software agency and freelancers are not three prices for the same thing. They are three genuinely different products, sold in three different units, carrying three different kinds of risk. Comparing them on hourly cost alone is the single most expensive mistake in this decision, because the cheapest unit of time almost never produces the cheapest unit of working software.
The choice matters more than most buyers expect. It decides how quickly you can start, how much knowledge stays in your business when the project ends, who is accountable when a release breaks, and whether your technology strategy is something you own or something you rent. A team of in-house developers gives you permanence and context at the cost of flexibility and a long lead time. An agency gives you a working machine on day one at a visible margin. Freelancers give you speed and specialism with almost no safety net.
This guide compares all three on true 2026 UK cost, delivery speed, risk, control and exit terms, with indicative figures, a scoring method you can apply to your own situation, and the hybrid arrangement most companies actually settle on. It pairs with our breakdown of custom software development cost if you are still sizing the work itself.
Table of contents
- What In-House Developers, an Agency and Freelancers Really Cost
- Why In-House Developers Look Cheaper Than They Are
- What a Software Agency Actually Sells
- What Freelancers Do Better Than Anyone
- Speed, Risk and Control: In-House Developers Against Both Alternatives
- Matching the Model to Your Stage and Workload
- The Hybrid Model Most UK Companies End Up Running
- A Scoring Method for In-House Developers vs Agency vs Freelancers
- Contracts, Code Ownership and Exit Risk
- Common Mistakes When Hiring In-House Developers
- How to Run the Decision in Four Weeks
- Frequently Asked Questions
- References
What In-House Developers, an Agency and Freelancers Really Cost
Cost comparison in this market is routinely done wrong, because the three options quote in incompatible units. A salary is an annual figure that excludes a third of what the person costs you. A day rate is a fully loaded number that includes everything. Putting them side by side without normalising is how a business convinces itself that in-house developers are half the price of an agency, then discovers otherwise eighteen months later.
The salary is roughly two-thirds of the true number
A £70,000 salary is not a £70,000 cost. Employer National Insurance, the workplace pension contribution, equipment, software licences, training budget, recruitment fees amortised over the expected tenure and a share of management time all sit on top. The employer National Insurance rates and workplace pension duties alone add a meaningful percentage before anything else. Realistically, in-house developers cost between 1.4 and 1.6 times their gross salary.
Day rates are not comparable to salaries
An agency or freelance day rate already contains the on-costs, the bench time, the holiday, the sick pay and the profit. To compare it fairly, convert it to an annual equivalent using productive days rather than calendar days — roughly 210 to 220 billable days a year once holiday, illness and training are removed. A £600 day rate is therefore about £126,000 a year of continuous engagement, but you are only obliged to buy the days you need.
Utilisation is the number that decides the winner
The comparison turns entirely on how much work you genuinely have. In-house developers are a fixed cost that you pay whether the backlog is full or empty, so they win decisively at high, sustained utilisation. Suppliers are a variable cost that you switch off, so they win when demand is lumpy. Most businesses overestimate their steady-state demand in year one and underestimate it in year three.
The 2026 UK picture side by side
The table below normalises all three routes to an annual equivalent for one mid-to-senior engineer. Treat the figures as indicative market bands rather than quotes; regional variation between London and the North is significant, and specialist skills sit above these ranges.
| Factor | In-house developers | Software agency | Freelancers |
|---|---|---|---|
| Headline price | £45,000-£95,000 salary | £500-£1,100 per day | £350-£700 per day |
| Hidden on-costs | 40-60% on top | None, included | None, included |
| Annual equivalent | £63,000-£150,000 | £105,000-£231,000 | £74,000-£147,000 |
| Time to productive start | 10-20 weeks | 2-6 weeks | 1-3 weeks |
| Cost when demand stops | Full, plus notice | Zero after notice period | Zero, often immediate |
| Exit cost | Redundancy risk | Contractual notice | Minimal |
| Knowledge retained | High | Medium, if documented | Low |
| Best suited to | Continuous product work | Defined builds and scale-ups | Specialist or short work |
Why In-House Developers Look Cheaper Than They Are
Every business that has run the numbers on paper has concluded that in-house developers are the economical option. The arithmetic is not wrong so much as incomplete. Four costs are consistently left out, and together they explain most of the gap between the spreadsheet and the management accounts.
Recruitment is a real and repeating cost
Filling a mid-level engineering role in the UK takes eight to fourteen weeks and costs between fifteen and twenty-five per cent of first-year salary if an agency is involved. Do it in-house and you pay in senior engineering time instead, which is not free either. Because software people move, that cost repeats on a cycle rather than being a one-off; the CIPD’s work on turnover and retention puts the churn rate high enough to matter to a small team.
Bench time is the cost nobody budgets
A supplier absorbs the gaps between your projects. Employed in-house developers do not disappear when the roadmap stalls waiting on a decision, a design or a third party. In a small team, ten to twenty per cent of paid capacity typically goes on waiting, and it is invisible because nobody invoices you for it.
Attrition resets the clock on context
The genuine advantage of in-house developers is accumulated context: they know why the odd bit of the billing logic exists and which integration is fragile. When someone with three years of that context leaves, you lose an asset that never appeared on any balance sheet, and the replacement takes six months to rebuild a fraction of it.
Management overhead is a hidden headcount
Somebody has to do one-to-ones, performance reviews, technical hiring, holiday cover and career conversations. For a team of five in-house developers, that is a meaningful slice of an engineering manager’s week, and if you do not have an engineering manager, it lands on your most senior engineer and reduces their output accordingly.
What a Software Agency Actually Sells
The agency margin is the part buyers resent and the part that is easiest to misread. You are not paying a premium for the same hours you could buy elsewhere. You are paying for a functioning delivery organisation that exists whether or not you are currently using it.
You are buying a team, not a person
An agency assigns a group with complementary skills — backend, frontend, quality assurance, design, delivery management — sized to the work rather than to a headcount plan. Assembling that mix from in-house developers means five hires and a year, or it means one generalist doing four jobs badly. A software development company already has the shape.
Process and governance come bundled
Established suppliers arrive with continuous integration, code review standards, environment management, release processes and a definition of done, all of which took years to build. Verifiable practices such as those in the GOV.UK Service Manual or the DORA delivery metrics are worth asking about directly, because they are the difference between a team that ships weekly and one that ships quarterly.
The margin is the price of continuity
When an agency engineer resigns, that is the agency’s problem. Your delivery continues, because the contract is for capability rather than for a named individual. When one of two in-house developers resigns mid-project, that is entirely your problem, and there is no contractual remedy for it. Priced correctly, that risk transfer is worth a great deal.
Where agencies genuinely disappoint
They are not a universal answer. Agencies are weakest on deep domain knowledge, on work that arrives in unpredictable dribs and drabs, and on long-term ownership of a system nobody is actively building any more. If you cannot describe what you want with reasonable precision, the model amplifies the ambiguity rather than absorbing it. Our guide to outsourcing strategies covers when the model fits and when it does not.
What Freelancers Do Better Than Anyone
Freelancers occupy a distinct position that neither of the other options fills well: individual expertise, available quickly, priced without institutional overhead. Used deliberately they are excellent value. Used as a substitute for a team they are the riskiest of the three.
Speed to start is unmatched
A good contractor can be reviewing your codebase within a week. No recruitment process, no statement of work negotiation, no procurement cycle. When something is genuinely urgent — a security fix, a compliance deadline, a migration window — this is decisive, and it is why even organisations with strong in-house developers keep a contractor list.
Specialist depth at exactly the right moment
You will not hire a full-time Kubernetes specialist, a payments integration expert or an accessibility auditor, and you should not try. Buying three weeks of a specialist who has done it forty times is dramatically better value than six months of your in-house developers learning it once, and the knowledge transfer is worth insisting on in the contract.
The single point of failure problem
One person has one illness, one holiday, one better offer. There is no bench, no cover, no second opinion in code review and no institutional memory beyond what they choose to write down. On anything longer than a few months, that concentration of risk is the reason freelancers should complement a team rather than constitute one.
IR35 and the UK compliance overhead
Engaging contractors in the UK brings status determination obligations. The off-payroll working rules and the underlying employment status tests determine whether you must operate PAYE, and getting it wrong is expensive. Medium and large companies carry the determination burden themselves, which is administrative work that in-house developers on payroll simply do not generate.
Speed, Risk and Control: In-House Developers Against Both Alternatives
Cost gets the attention, but speed, risk and control usually decide the outcome. The three routes behave so differently on these axes that the right answer is often obvious once you stop looking at rate cards.
Time to first working software
Freelancers start fastest, agencies start quickly with a full team, and in-house developers start slowest because you must find, notice-out, onboard and ramp them. Twelve to twenty weeks from decision to meaningful output is normal for a first hire, and no amount of budget compresses it much. If your deadline is inside six months, building the team is not a plan.
Who actually carries delivery risk
With in-house developers, you carry all of it: estimation risk, capability risk, attrition risk, delivery risk. With a fixed-price agency contract, a defined portion transfers to the supplier. With freelancers, you carry almost all of it again, minus the employment obligations. Our comparison of fixed price versus time and materials explains how much genuinely transfers under each model.
Control over priorities and direction
This is where in-house developers are unbeatable. You can change direction on a Monday morning without a change request, a commercial conversation or a two-week notice period. Suppliers can be responsive, but every reprioritisation passes through a contract. For genuinely exploratory product work, that friction is a real tax.
Knowledge retention after the work ends
An agency can document well and hand over cleanly if you make it a contractual obligation and pay for it. A freelancer rarely does either by default. In-house developers retain knowledge automatically, which is the strongest single argument for the model and the reason most product companies eventually build a core team regardless of cost.
| Dimension | In-house developers | Software agency | Freelancers |
|---|---|---|---|
| Speed to start | Slow | Fast | Fastest |
| Ability to scale up | Slow and permanent | Fast and reversible | Fast but capped |
| Ability to scale down | Painful | Contractual | Immediate |
| Delivery risk owner | You | Shared or supplier | You |
| Domain knowledge growth | Compounds | Partial | Leaves with them |
| Breadth of skills covered | Limited by headcount | Broad | Narrow and deep |
| Cover for absence | Only if team is large | Built in | None |
| Priority changes | Instant | Change control | Negotiable |
| Default IP position | Employer owns | Assigned by contract | Contractor owns unless assigned |
| Best value when | Demand is constant | Scope is definable | Need is specialist |
Matching the Model to Your Stage and Workload
There is no universally correct answer, only a correct answer for a given stage, workload shape and risk appetite. The pattern below holds across most UK companies we see, and recognising which row you are in resolves the question faster than any amount of cost modelling.
Before product-market fit
Speed of learning beats everything, and the work changes weekly. A small agency or two strong freelancers will get you to a testable product faster and cheaper than recruiting, and you avoid hiring permanently for a product that may not survive contact with customers. Our MVP development services exist for exactly this phase.
Scaling a product that is working
Once demand is proven and the backlog is permanently full, the economics flip decisively toward in-house developers. Sustained utilisation is the condition under which fixed cost beats variable cost, and by this point the accumulated domain knowledge has real commercial value. Most companies begin hiring here and keep supplier capacity for peaks.
Steady-state maintenance
A live system with modest change needs perhaps a fifth of a person, which is impossible to hire and easy to buy. A support retainer or a trusted contractor on a few days a month is far more sensible than an underemployed engineer, and it avoids the boredom-driven attrition that kills maintenance roles. See our note on software maintenance cost for the sizing.
Peaks, deadlines and one-off projects
A regulatory deadline, a platform migration or a seasonal push needs capacity you will not want afterwards. This is the classic case for a supplier, and hiring in-house developers to cover a temporary spike is how businesses end up with a redundancy conversation eighteen months later.
The Hybrid Model Most UK Companies End Up Running
Ask a hundred technology leaders how they staff delivery and very few describe a pure model. The mature arrangement is a small permanent core surrounded by elastic supplier capacity, and it is worth designing deliberately rather than arriving at accidentally.
A small core plus elastic capacity
Two or three in-house developers who own architecture, code review and production, plus an agency or contractor pool that expands for projects. You retain the knowledge and the control where they matter, and you buy the peaks without carrying them. This is the shape that survives both a hiring freeze and a sudden roadmap.
Who should own architecture
The core team, without exception. Architectural decisions outlive every supplier relationship, so the people who will still be there in three years should make them. Suppliers can propose, build and challenge, but the final call and the technology consulting direction belong with people whose incentives match yours over the long term.
Making the handovers actually work
Hybrid models fail at the seams. Insist on shared repositories rather than delivered zip files, one continuous integration pipeline rather than two, joint code review, and documentation as a definition-of-done item. Adopting shared agile methodologies and one deployment process removes most of the friction that gives mixed teams a bad reputation.
Cybersecurity and access across mixed teams
A blended team multiplies the number of people holding credentials, so cybersecurity practice has to be explicit: named accounts, least privilege, revocation on the day an engagement ends, and no shared logins. The NCSC Cyber Essentials controls are a sensible baseline, and the discipline costs less than any single incident it prevents.
A Scoring Method for In-House Developers vs Agency vs Freelancers
Rather than argue the general case, score your specific situation. The method below takes about twenty minutes and produces a defensible recommendation you can show a board, which is usually the real deliverable.
The seven factors that predict the outcome
Score each factor from one to five for how strongly it applies to you: sustained workload, need for speed, scope clarity, specialist skills required, importance of retained knowledge, budget flexibility, and tolerance for delivery risk. These seven explain most real decisions; adding more factors adds precision you do not have.
How to weight them honestly
Multiply each score by the weight in the table, then total each column. Weight sustained workload and retained knowledge highest if you are building a product you will own for years. Weight speed and scope clarity highest if you are delivering a defined project against a date. The weights matter more than the scores, so agree them before you look at any supplier.
Reading the result
A margin under ten per cent between two columns is a tie, and a tie means the hybrid model. A clear win for in-house developers with a workload score below three is a warning that you are about to hire for demand you have not yet proven. Re-run the exercise annually, because the answer legitimately changes as the business does.
A worked example
A twenty-person SaaS business with a full backlog, a stable product, moderate speed pressure and no exotic skill needs scores high on workload and knowledge, low on specialism. In-house developers win that column comfortably, and the sensible plan is two permanent hires with an agency retained for the integration work nobody wants to specialise in.
| Decision factor | Weight | Favours in-house developers | Favours agency | Favours freelancers |
|---|---|---|---|---|
| Sustained workload | x3 | Constant, full backlog | Project-shaped | Occasional |
| Need for speed | x3 | No urgent deadline | Weeks, not months | Immediate |
| Scope clarity | x2 | Exploratory | Well defined | Narrow and clear |
| Specialist skills | x2 | Common stack | Mixed disciplines | Deep niche |
| Retained knowledge | x3 | Business critical | Useful | Not important |
| Budget flexibility | x2 | Fixed annual budget | Capital project budget | Small and variable |
| Risk tolerance | x1 | High, you own it | Low, transfer it | High |
| Typical winning total | – | Mature product companies | Defined builds and rescues | Gaps and spikes |
Contracts, Code Ownership and Exit Risk
The legal position differs sharply across the three routes, and the default outcome is only safe in one of them. This is the part of the decision that quietly determines whether you own what you paid for.
Employment gives you ownership by default
Work created by employees in the course of employment belongs to the employer under UK law, which is why in-house developers are the low-risk option for intellectual property. The GOV.UK guidance on ownership of copyright works sets out the principle, and it is one of the few places where the default position needs no contractual repair.
Agency contracts need an explicit assignment
A supplier owns what it creates unless the contract assigns it to you on payment. Reputable agencies assign willingly; the clause to check is whether assignment is triggered by delivery or by payment, and what happens to pre-existing components licensed rather than assigned. Our software development contract checklist sets out the wording that matters.
Freelance contracts are the riskiest by default
A contractor is not an employee, so without a written assignment they own the copyright in what they wrote for you. Many businesses discover this years later during due diligence, when a buyer asks for a chain of title nobody can produce. A short assignment clause solves it entirely, and the intellectual property overview is worth reading before you sign anything.
Plan the exit from day one
Whichever route you pick, write down what leaving looks like: repository access, credentials, documentation standard, notice period and a handover window. The statutory notice framework governs employment, but for suppliers it is whatever you negotiated. Detailed guidance on source code ownership covers the clauses in full.
Common Mistakes When Hiring In-House Developers
Most of the disappointment attributed to this decision comes from a handful of avoidable errors, and they cluster around the in-house route because it is the least reversible of the three.
Hiring for the build rather than the decade
The person who thrives on a greenfield build is not always the person who wants to maintain it for five years. Hiring in-house developers on the strength of a launch and then handing them a maintenance backlog is a reliable route to a resignation at month fourteen, and a second recruitment cycle you did not budget for.
One senior engineer with nobody to argue with
A lone senior with no peer review is a governance gap, not a saving. Every architectural decision goes unchallenged, and quality drifts in whatever direction that individual prefers. If you can only afford one hire, buy a few days a month of external review — an established IT outsourcing relationship is a cheap corrective.
Treating cost optimisation as headcount reduction
Cutting developers rarely reduces cost per unit of delivered software; it usually raises it, because the remaining people spend their time on interruptions. Genuine cost optimisation in engineering comes from automation, better tooling and shorter feedback loops, and in-house developers with a working DevOps pipeline deliver several times the output of the same people without one.
Skipping the technical assessment
Non-technical founders frequently hire on rapport, then have no way to evaluate the work for a year. Borrow a senior engineer for the interview, or pay a supplier for two days of assessment. Vetting in-house developers properly costs a fraction of the salary you are about to commit to for several years.
How to Run the Decision in Four Weeks
Treat this as a short, structured exercise rather than a standing debate. Four weeks is enough to reach a defensible answer without stalling the work that prompted the question.
Week one: size the demand honestly
Write down the next twelve months of engineering work in weeks of effort, then halve your confidence in it. If the total is under about forty weeks a year, in-house developers are hard to justify on utilisation alone and you should be shopping for a supplier or a contractor.
Week two: test the market on both sides
Run a recruitment advert and request two supplier proposals in parallel. You will learn more about real salary expectations and real day rates in a fortnight of market contact than from any survey, and the two data sets make the comparison concrete rather than theoretical.
Week three: score and stress-test
Complete the scoring table, then stress-test the winner against two scenarios: the roadmap doubles, and the roadmap halves. A model that only works in the expected case is not a decision, and the hybrid arrangement usually survives both tests better than either pure option.
Week four: commit and design the seams
Whichever way it goes, write down the operating model — who owns architecture, how code review works, what the definition of done is, and how an engagement ends. Businesses that do this rarely regret the choice; those that skip it tend to blame the model for problems that were really about missing structure.
Frequently Asked Questions
Are in-house developers cheaper than an agency over three years?
Usually yes on paper, at roughly half the cost per productive day, but only if utilisation stays high and nobody leaves. At sixty per cent utilisation with one resignation, the gap narrows sharply. The honest answer is that in-house developers are cheaper when you have enough constant work to keep them busy, and more expensive when you do not.
Can freelancers build an entire product?
They can, and it happens often at the earliest stage, but you are accepting concentrated risk: no cover, no peer review and no continuity. If you go this route, insist on your own repository, documented decisions, a written IP assignment and at least a monthly external code review so that a departure is inconvenient rather than fatal.
How many in-house developers do I need before it works?
Three is the practical minimum for a self-sufficient team, because it allows peer review, holiday cover and a second opinion on architecture. Below three you are exposed to single-person risk and should supplement with external capacity rather than pretend the team is complete.
Should my first technical hire be a contractor?
Often, yes. A senior contractor can establish the architecture, tooling and standards, then help you interview permanent staff. It converts a slow, high-stakes hire into a fast, reversible one, and the standards they set are what future in-house developers inherit.
Which option is fastest if I have a deadline this quarter?
A freelancer for narrow work, an agency for anything requiring more than one discipline. Recruiting in-house developers will not deliver inside a quarter under any realistic assumption, so if the deadline is fixed the decision has effectively been made for you.
How do I keep in-house developers once I have hired them?
Interesting work, a functioning pipeline, peer review and a visible path for progression, in roughly that order. Pay matters at the margin, but engineers leave environments more often than they leave salaries, and a team of two with no technical leadership is an environment people leave.
Can I change my mind later?
Yes, and most companies do. Moving from suppliers to in-house developers is straightforward if you own the repository and the documentation. Moving the other way is harder because it involves people, so keep the exit conditions written down from the beginning whichever direction you start in.
References
GOV.UK: Understanding off-payroll working (IR35)
GOV.UK: Employment status – self-employed and contractor
GOV.UK: National Insurance rates and categories
GOV.UK: Workplace pensions – employer duties
GOV.UK: Ownership of copyright works
GOV.UK: Intellectual property, an overview
GOV.UK Service Manual: Agile delivery
CIPD: Employee turnover and retention
