Should we build an in-house dev team or outsource? Cost, speed and where the knowledge ends up

There is no company-level answer to this question. You decide capability by capability. Work that sets you apart from competitors, changes often and depends on domain knowledge belongs inside. Work that is well defined, bounded, temporary or needs a specialist you would use a few weeks a year comes out cheaper and faster from outside. Most companies end up running both, and the usual mistake is not the model they picked but which work they sent to which side.

The question is "which work," not "which team"

Geoffrey Moore's core versus context split makes this easy to reason about. Core is the work that is the reason a customer pays you, the part that creates differentiation. Context is the work that has to happen but that nobody chose you for. Both matter, both hurt when they break, and they do not have to live in the same place.

Say you are a retailer competing on pricing and promotion rules. The pricing engine is core: rules change several times a week, the person who wants the change sits down the hall, and a two-day delay shows up in revenue. In the same company, the e-invoicing integration, the payment provider connection and the app store release process are context. You specify them once, they follow a standard, and somebody touches them twice a year.

Classification also shifts over time. A feature that differentiates you today becomes table stakes in three years, and holding it inside stops paying for itself. Revisit the list annually.

What an in-house team actually costs

Salary is the visible and smallest part. On top of gross pay come statutory employer contributions, which vary by country but are rarely small. In Turkey, for example, the employer side of social security plus unemployment insurance runs to roughly 23.75 percent of gross pay in 2026, and a change effective January 2026 raised the employer share by one point while cutting the offsetting discount for non-manufacturing companies from four points to two. Software firms sit on the non-manufacturing side, so that landed straight on payroll.

Then come the accruals that never appear in a monthly cost sheet: severance liability, notice periods, unused leave balances. They are invisible until somebody leaves, and then they arrive as a single line.

Hiring time is the next item. Workable's platform data for IT and software development roles puts time to fill at 68 days globally and 85 days in Europe, with time to hire, the part that starts once a candidate is in the pipeline, at around 33 days. Most of the wait is finding the right person, not interviewing them. The work does not stop during those weeks. It piles up.

One more thing that estimates miss: a developer is not a team. Without a second person to review code, someone to own the deployment pipeline, someone to design the interface and someone to run acceptance testing, a one-person team turns into a one-person dependency within a quarter. We wrote separately about what happens when the only person who knows the code leaves. Building in-house is, in practice, a decision about a core of two or three people, not one.

What an outsourcing quote leaves out

The rate or the project price is right there in the proposal. What is not in it: the effort of writing down what you want, the first few weeks the vendor spends learning your business, the decision queue that builds up on your side, the management time the relationship consumes, and the cost of transition when the contract ends.

The decision queue is the most underestimated of those. An external team that is waiting for your answer is not working, and it is usually waiting. When delivery slips, the cause is more often an unanswered question than a slow vendor. Writing a decent requirements document and naming one counterpart who can decide daily rather than weekly removes most of this cost.

Transition risk comes second. If the repository, the cloud account, the domain registration and the app store accounts live under the vendor's identity, your exit cost is much higher than whatever the contract says. Our posts on source code ownership and escrow and handover when you switch vendors go through both in detail.

Six questions per capability

Answer these for each line on your capability list. Three or more answers pointing inward means keep it inside.

1. Does this work differentiate you, or does it work the same way at every company in your industry?
2. How often do the rules change? A business rule that changes weekly gets expensive to run through a contract.
3. How long will the need last? Hiring a team for a six-month job is as wrong as buying hours for a five-year one.
4. Can you write the work down? What you cannot specify clearly will cause trouble under a fixed-price contract and with an external team alike. Fixed price versus time and materials covers that split.
5. What do you lose if this knowledge leaves the company? If the answer is "we cannot deliver what we promised customers," keep it inside.
6. Can you hire and retain that skill at all? Penetration testing, SRE or data engineering expertise you need a few weeks a year is both expensive and hard to hold as a full-time role.

Three models, three different risks

With staff augmentation, external developers work inside your team and your process. You keep the management load, and in return most of the knowledge accumulates with you. With turnkey delivery, responsibility moves to the vendor, but everything outside the agreed scope becomes a contract discussion, and if acceptance criteria were never written, the negotiation starts at delivery. The third model is a vendor running an end-to-end product team. It is the fastest to stand up and creates the deepest dependency.

If there is one pattern to avoid, it is a single external developer with no counterpart inside. Nobody reviews the code, no decision gets recorded, and when that person moves on there is nothing legible left behind. It looks like the cheap option and reliably produces the expensive outcome.

The mix is the norm, not the exception

Deloitte's 2024 Global Outsourcing Survey, based on more than 500 executives, puts two findings side by side: 70 percent had selectively brought scope back in-house over the previous five years, and 80 percent still planned to maintain or increase their investment in third-party services. Bringing work back is not a sign of failure. It is a normal step in the lifecycle.

Assume it from the start and the contract changes shape: documentation as a delivery condition, account and access ownership spelled out, a defined transition period and support during that transition. These clauses get written while the relationship is good. They cannot be written after it sours.

What stays inside even when you outsource

Product ownership and acceptance criteria stay inside. Whoever decides what the software should do has to sit in your company, otherwise the vendor both does the work and signs it off.

Architecture decision rights stay inside too. Which language, which database, which cloud provider is a ten-year cost decision, and you pay that cost, not the vendor. Choosing a technology stack lists the criteria worth arguing about.

Account and access ownership is the third, and this is where the security side starts. The cloud account, the repository, the domain and the store accounts should be created under your company's identity. The vendor gets named accounts rather than a shared login, only the permissions the work requires, and multi-factor authentication. Write down who verifies that access is revoked the same day a vendor's team member rolls off. Put credentials in a secrets manager instead of sending a database password over email or chat; secrets management and the authorization model cover the practical setup. With these four things in your hands, changing vendors is a week of work. Without them, it is a project.

Write two three-year scenarios

Decide with two simple tables rather than a feeling. In-house: headcount times gross salary times the employer multiplier, plus severance accrual, plus the cost of work deferred during the hiring window, plus equipment, licences and cloud, plus the manager's time. Outsourced: contract value, plus the analysis and acceptance effort on your side, plus onboarding and transition cost, plus 10 to 20 percent for scope change.

If the two totals land within 20 percent of each other, do not decide on cost. In that range the deciding factors are control, speed and where knowledge accumulates. If the gap is larger than 20 percent, check the numbers once more, because the missing line is usually the hiring window or the scope change allowance.

One caution on comparing quotes: in-house cost shows up on payroll and outsourced cost shows up on an invoice, and those two are not directly comparable. R&D tax credits, technology zone regimes and employment incentives differ by country and can move the in-house side significantly. In Turkey, for instance, income from software, design and R&D activities carried out inside a technology development zone is exempt from income and corporate tax through 31 December 2028 under the temporary article 2 of law 4691, alongside wage exemptions and partial state coverage of the employer's social security share for qualifying personnel. Check the current conditions with your accountant before you put a number in the table.

Three steps that fit in this month

One: write a capability list of 10 to 15 lines on a single page. Pricing, integrations, mobile app, reporting, infrastructure, security monitoring, and so on. Mark each line core or context, and note separately the lines your team disagrees about. That is where the real discussion is.

Two: write the two three-year scenarios for the top three lines. Rough numbers are fine. What matters is that every line item is on the table.

Three: whichever model you choose, get account ownership and acceptance criteria in writing this month. Those two protect you independently of the sourcing decision.

At Wedevit we give this advice as an independent party, and for some lines our answer is "build this inside, let us set it up and train your team." All our work is delivered remotely. A good starting question: can you write down in one sentence what sets you apart from your competitors, and whose account holds the code for that sentence today?