Ã… skape fremragende programvare
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Nunzio Giugliano
aug 27, 2026 • 14 min read
In-house vs outsourcing software development is not a philosophical question, and it produces bad answers mainly because of how it is posed. Before anything else: we sell outsourced engineering, so one of the three answers below pays us and the other two do not. You should discount what we say accordingly, which is why the rest of this article is built on published benchmarks and arithmetic you can redo rather than on our opinion.
The standard framing of in-house vs outsourcing contains three errors, and each one is enough on its own to reverse the conclusion.
It presents two options when there are more: hiring, buying, the blend of the two that most companies actually run, and the option your CEO has probably already raised: generating what you need with AI tooling. Four columns, not two.
It compares a salary to a rate card: neither figure is a cost, so a comparison built on them starts wrong. A salary excludes the employer loading and every non-payroll item attached to a person. A rate card excludes the management time you spend steering the supplier.
It compares them over one year when the commitment is three: this is the error that matters most, because in-house vs outsourcing inverts across it. Outsourcing usually wins year one and in-house often wins by year three, so the horizon you pick decides the answer before you look at a number.
The consequence: whoever runs the arithmetic arrives at the answer they already wanted, because a framing with that much slack accommodates any conclusion. A CTO who wants to hire can produce a model that says hire. A CFO who wants to cut headcount can produce one that says outsource. Both look rigorous, and both answer a question the framing already decided.
Three variables actually decide in-house vs outsourcing software development, and this article works through all three: team size, project type and growth stage. Most companies with 5 to 30 developers end up with a blend, so the useful question is not which model wins but which work sits where.
What should I compare, if not salary against rate card?
Fully-loaded cost against total supplier cost, over three years, per workstream. That means salary plus employer loading plus tooling plus management time on one side, and rate card plus vendor management plus specification and review effort on the other. Both of the numbers people usually quote in an in-house vs outsourcing comparison exclude the items that scale worst.
Half of the in-house vs outsourcing comparison is a number most engineering leaders carry in their head as a gross salary, and the employer's real cost is materially higher. This is not a vendor estimate, it is a published statistic, updated quarterly, and it decides half of any in-house vs outsourcing model.
The US Bureau of Labor Statistics Employer Costs for Employee Compensation release for March 2026 puts benefits at 30.1 percent of total employer compensation cost for private industry workers, rising to 32.7 percent at the 90th wage percentile, which is the relevant end of the distribution for software engineering.
Against the BLS median annual wage for software developers of 133,080 dollars, the 30.1 percent loading implies roughly 190,000 dollars before a single non-payroll line item. The 32.7 percent figure is a deliberate ceiling rather than a median case, because it is drawn from the 90th wage percentile: applied to the same wage it gives roughly 198,000 dollars. Take 1.43 as the floor and 1.49 as the conservative upper bound, and note that almost nobody applies either when they open a comparison spreadsheet.
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
One caveat, in an article about not accepting unexamined numbers: that loading is an average across all private industry occupations rather than a software-specific figure. Use it to size the gap in your own in-house vs outsourcing model, then replace it with your own payroll data.
For an EU reader the shape holds and the level does not. Eurostat puts average hourly labour costs across the EU at 34.90 euro in 2025, with non-wage costs at 24.8 percent and a spread from 12.00 euro in Bulgaria to 56.80 euro in Luxembourg (lower loading, far wider range, same lesson).
Then there are the items that never make the in-house vs outsourcing comparison at all:
The three-year view is where hiring looks best, and the argument deserves full strength; domain context compounds, and it is the one item in an in-house vs outsourcing model that grows on its own. A team that has been inside your problem for three years is faster at your problems specifically, in a way that does not transfer and cannot be bought back later at any price. If the software is your product and will still be running in five years, this is the strongest honest case for hiring, and we say so to prospects regularly.
The offsetting force sits on the same horizon. Attrition re-pays the ramp cost and removes context from the building, and it removes the most context when the person leaving understood the oldest part of the system. BLS projects employment of software developers to grow 16 percent between 2024 and 2034 against 3 percent for all occupations, which is not a labor market where retention is a given.
The asset here is your model rather than our total. Populate the items above from your own payroll and tooling bill and you will have a number you can defend to a CFO. What you will find is that in-house vs outsourcing is routinely settled by comparing a supplier rate card against a figure that excludes roughly a third of its own cost.
The outsourcing half of in-house vs outsourcing names four commercially distinct products, and most disappointment in this category comes from buying one while expecting another. The staff augmentation vs outsourcing distinction is the one buyers get wrong most often, so it comes first.
Staff augmentation: You rent capacity and keep management, architecture and accountability. Cheapest to start, and its real cost lands on your managers rather than in your budget. It fails when the client assumed they were buying direction and discovered they had bought hands.
Dedicated team: The dedicated development team model puts a persistent team on your backlog under someone else's employment contract. It is the only outsourced model where retained context is achievable, and the closest substitute for hiring. It is also where supplier attrition hurts you most, invisibly.
Fra idé til lansering lager vi skalerbar programvare som er skreddersydd til dine forretningsbehov.
Samarbeid med oss for å akselerere veksten din.
Fixed-scope project: You buy a date and a defined output, and the supplier carries the estimation risk and prices it in. It fails on change, which is where in-house vs outsourcing gets decided in practice. Ask any supplier for their historical ratio of change-order value to original contract value before you sign, and treat a refusal as an answer.
Outcome or product ownership: Rare, expensive, and the only model where the supplier's incentive is aligned with the software working rather than with it being delivered. Most buyers who ask for this want a fixed-scope project with better language in it.
The rate card is not the cost, exactly as the salary is not the cost. Add vendor management time, specification effort, review effort, onboarding a supplier into your domain, and the eventual handover, all of which belong in an in-house vs outsourcing model as explicit line items. Leaving them out is how outsourcing gets flattered in an in-house vs outsourcing comparison, and it mirrors leaving management overhead out of the in-house column.
On geography, honestly. Offshore, nearshore and onshore are different products at different prices. We are EU-based and not the cheapest hourly option on anyone's rate card. What the difference buys is timezone overlap, a shared regulatory context, and enforceability. If none of those matter for your workstream, the cheaper rate is genuinely cheaper and you should take it.
Of the four, we sell dedicated teams and fixed-scope projects. We do not sell staff augmentation, because renting people out by the hour rewards us for headcount rather than outcome. Over three years outsourcing looks worst on rate escalation and on context living elsewhere, and best on having no severance exposure, no recruiting cycle, and capacity that can stop.
The common thread across in-house vs outsourcing: each model transfers a different risk, and none of them transfers the domain knowledge problem.
What is the difference between staff augmentation and outsourcing?
Staff augmentation rents you capacity and leaves management, architecture and accountability with you. Outsourcing in its stronger forms transfers responsibility for a defined output as well as the work. The most expensive mistake in this category is buying the first while expecting the second: you get people who do exactly what they were asked, on a project nobody was steering.
In-house vs outsourcing had two columns until recently. The third is the one your CEO has already asked about, and it deserves a straight answer rather than a defensive one. Existing staff, or people who are not engineers at all, generating what they need with AI tooling instead of hiring for it or buying it. The enterprise vocabulary for this is the citizen developer, and the citizen developer is now producing working software rather than spreadsheets.
Start with the case for it at full strength, because a weak version of the opposing argument would discredit everything else here. Internal dashboards. One-off migrations. Scripts. Glue between two SaaS products. The quarterly report somebody rebuilds by hand every quarter. Generating those is now cheaper than writing a specification precise enough to hand to a supplier. A category of work that used to justify a contractor no longer does.
The concession, and we mean it commercially: this removes work from suppliers like us, and it should. A supplier still charging a discovery phase to build an internal dashboard is selling something the client can now do in an afternoon. We have stopped quoting for that category.
Vi designer og bygger digitale produkter av høy kvalitet som skiller seg ut.
PÃ¥litelighet, ytelse og innovasjon i alle ledd.
Cost it on the same basis as the other two columns. In-house vs outsourcing had no column where the build cost collapses toward zero, and now it does. The three-year items do not: maintenance, whoever inherits the thing, and the incident if it touches real data.
The failure mechanism is structural rather than a matter of skill: you cannot review what you cannot read. In an in-house team or at a supplier, somebody in the chain can read the output and will notice when it is wrong. When a business analyst generates a tool, review capacity in the loop is zero, and that is not a limit the generator can perceive or report.
There is a governance item most companies have not priced either. A tool generated inside a business unit runs on real infrastructure against real data, and is very likely absent from any asset register or record of processing. This is shadow IT with the lowest barrier to entry it has ever had.
So the rule is financial rather than moral. Generate freely wherever the honest answer to "who maintains this" is nobody, because we will regenerate it or delete it. The moment that answer is a person's name, you have taken on a maintenance liability, and you are back in the in-house vs outsourcing comparison with a third column added to it.
Where it stops: anything customer-facing, anything holding personal or special-category data, anything you would explain to an auditor, and anything whose failure is not obvious immediately. That last one catches more teams than the other three combined.
Who owns a tool that a business unit generated?
By default, nobody, and that is the whole problem. Assign an owner at the moment of creation or accept explicitly that the tool is disposable. The middle state, where a spreadsheet-replacement quietly becomes load-bearing and has no owner, is the one that produces an incident nobody can debug.
All three columns, over three years. Populate the blanks from your own payroll and your own supplier quotes. The blanks are deliberate: a figure we invented for your business would be worth less than an honest gap with a method attached.
| Line item | In-house | Outsourced | Generated in-house |
|---|---|---|---|
| Setup, year 0 to 1 | |||
| Recruiting, fee or internal recruiter time | Ja | None | None |
| Equipment, licenses, per-seat tooling | Ja | Supplier absorbs | Tooling seat only |
| Onboarding and ramp to first contribution | Highest | Moderate | None |
| Supplier selection and contracting | None | Ja | None |
| Specification effort | Lav | Highest on fixed-scope | Highest, and it is your own time |
| Run, year 1 to 3 | |||
| Compensation or rate card | Salary times 1.43 to 1.49 | Rate card | Near zero |
| Engineering management and lead time | High and rising with headcount | Moderate | None until it breaks |
| Vendor management time | None | Ja | None |
| Review effort | Internal | Internal, and often underestimated | None, and that is the risk |
| Escalation | Salary review | Rate escalation | Tooling price changes |
| Attrition and re-ramp | Ja | Yes, and invisible to you | Not applicable |
| Maintenance of what was built | Owned | Contracted or handed back | Unassigned by default |
| Exit | |||
| Severance and notice exposure | Ja | None | None |
| Handover and knowledge transfer | Internal | Contractual, if you wrote it in | None exists |
| The thing nobody can maintain | Rare | Rare | The main exit cost |
Total the in-house vs outsourcing columns twice, at twelve months and at thirty-six. The inversion between those two totals is the finding, and it is the one number in this article we cannot compute for you.
In-house vs outsourcing is usually answered with both, so the blend is the normal answer rather than the compromise answer, and what determines whether it works is not the ratio but where the seam falls.
The concession on in-house vs outsourcing first: blending distributes hiring risk and vendor risk at the same time, and that is real. If your supplier fails you still have a team. If your best engineer resigns you still have capacity.
Then price what it adds, which is the part almost nobody does. A blend adds a seam, and the seam costs four things: duplicated context, ambiguous ownership of a defect, two review cultures that disagree about what done means, and the standing question of who is on call at 3am. A hybrid is not the average of the two in-house vs outsourcing columns.
Conway's law is the mechanism rather than decoration. The seam in the organization shows up in the architecture. If your split does not follow a boundary the system already has, the architecture grows one exactly where the contract is.
The patterns that work are concrete:
The rule is three sentences. Split along an interface that already exists. Put review authority unambiguously on one side. Make one party accountable for the running system rather than for their half of it. The pattern that fails is splitting by overflow capacity, which produces two teams doing the same job with half the context each.
Said against our own interest: this seam cost applies when we are one half of the blend. A supplier who tells you a blended model is strictly cheaper is quoting you the rate card and not the seam. In-house vs outsourcing resolves to hybrid more often than not, and hybrid is never the cheap answer.
Does a hybrid model just cost the average of the two?
No, and budgeting it that way is why blends disappoint. A hybrid adds a seam: duplicated context, ambiguous defect ownership, two review cultures, and a question about who is on call. Priced as a line item it is manageable. Assumed away, it is the reason the model gets blamed for a coordination problem.
In-house vs outsourcing software development is answered per workstream, so the same company should reach different answers at the same time. The underlying error is having one organization-wide staffing policy at all.
Core product development: Compounding domain context, a long horizon, and the thing competitors cannot copy. Usually in-house, or a dedicated team behaving like one. This is where we most often tell a prospect to hire rather than buy from us.
Internal tools and integrations: This is where the old build vs buy software question has changed most, because a third answer appeared. Real value, bounded scope, no compounding advantage from owning the knowledge. This used to be the clearest case for outsourcing and it is now the clearest case for generating it in-house. The residual in-house vs outsourcing test is the data it touches, not the difficulty of the build.
Legacy modernization: The interesting case, because the usual in-house advantage is weaker than it looks: the domain knowledge is trapped in the existing system rather than held by the current team, while the cost of being wrong is highest. It is where doing it yourself is most tempting and least appropriate.
Spikes, prototypes and time-boxed experiments: Answer in-house vs outsourcing by buying capacity or generating it. Do not settle in-house vs outsourcing by hiring for a hypothesis.
| Project type | Default | What would change it |
|---|---|---|
| Core product | In-house, or a dedicated team run as one | You cannot hire in your market, or the product is not yet validated |
| Internal tools and integrations | Generate in-house | It touches personal data, or somebody's name is on maintaining it |
| Platform and infrastructure work | Outsourced or blended | It becomes a differentiator rather than a utility |
| Legacy modernization | Outsourced with in-house review authority | The original authors are still on staff and available |
| Code and security review | In-house, always | Nothing |
| Spikes and prototypes | Buy capacity or generate | The prototype is already carrying production traffic |
Then the growth-stage overlay, because team size changes the answer for an identical project type. At 5 developers every hire is a large fraction of capacity and a wrong hire is close to existential, which argues for capacity you can stop. At 30 the constraint is management bandwidth, which argues for fewer and more autonomous units rather than more people.
In-house vs outsourcing software development is a per-workstream decision. A company that answers in-house vs outsourcing once at the company level has it wrong for most of its work.
Still stuck on in-house vs outsourcing for your next hire?
Tell us the team size, the project type and the growth stage, and we will model the structure with you.
Our take, in one line
Cost all three options over three years, then decide per workstream, because the company-wide answer is wrong for most of your work.
This article was written by Nunzio Giugliano at Lasting Dynamics, an EU-based tilpasset programvareutvikling company that also builds AI software. We run agent-assisted delivery on fixed-scope engagements, which is why cost per workstream is a number we have to defend rather than estimate. The benchmarks above are dated and linked to their sources, so you can check whether they still hold when you read this. The model is yours to populate, and the arithmetic is yours to disagree with.
Over twelve months, outsourcing usually wins, because it front-loads far less recruiting, ramp and tooling cost. Over three years the comparison often inverts, as a team that has been inside your domain compounds context you cannot buy back. In-house vs outsourcing is decided by the horizon, and the horizon is the variable most comparisons leave unstated.
Materially more than the salary. US Bureau of Labor Statistics data for March 2026 puts benefits at 30.1 percent of total employer compensation cost for private industry workers, rising to 32.7 percent at the 90th wage percentile, which implies a multiplier of roughly 1.43 to 1.49 on gross pay before you add recruiting, equipment, licenses, cloud, per-seat tooling, training and the engineering-management time that scales with headcount rather than with output.
When the work is valuable but does not compound: bounded platform work, integrations, a capability you need for a defined period. Also when the alternative is a hire you could not keep busy or could not retain. Outsource least when the software is your core differentiator and will still be running in five years.
Often, yes. Generating an internal dashboard or a one-off migration is now cheaper than writing a specification precise enough for a supplier, and a category of work that used to justify a contractor no longer does. The limits are maintenance and data. Ask who will change the thing in eighteen months, and ask what data it touches. If nobody will maintain it and it holds nothing sensitive, generate it. If it holds personal data, it belongs in your asset register regardless of how quickly it was produced.
Running an internal team and external capacity against the same product, with the split following a boundary the system already has. It works when review authority sits unambiguously on one side and one party is accountable for the running system rather than for their half of it. It fails when the split is by overflow capacity, which produces two teams doing the same job with half the context each. It is not the average of the two cost columns, because it adds a seam that has to be budgeted.
Answer in-house vs outsourcing per workstream rather than per company, using three variables: team size, project type and growth stage. Core product that compounds and will outlive the decision points in-house. Bounded work with no compounding advantage points outward or, increasingly, at generating it yourself. Modernization points at whoever can carry the risk of being wrong. Most companies with 5 to 30 developers resolve in-house vs outsourcing as a blend, and the useful question is which work sits where.
Plan a quarter per workstream with a deliberate overlap, and do not move the second until the first has a measured result. The failure mode is never the contract, it is undocumented context, so require runbooks, architecture decision records and a real onboarding path from day one of any engagement, in either direction. Measure the transition by time to resolve a production defect in the transferred area rather than by velocity.
Forvandle dristige ideer til kraftfulle applikasjoner.
Let’s create software that makes an impact together.
Nunzio Giugliano
Nunzio Giugliano is a Marketing Specialist at Lasting Dynamics, where he works on SEO strategy, technical content and B2B research across AI, enterprise software and digital transformation topics. His work focuses on making complex technology subjects clear, useful and accessible for CTOs, founders, decision makers and technical teams.
