IT contractors or in-house developers? Why you need both

IT contractors or in-house developers? I think it's the wrong question. You need a strong internal team, and you need external experts alongside it. Without an internal team, there is no one to hand knowledge to and no one to own your systems. Without outsiders, the team slowly closes in on itself and loses touch with what is happening in the market. The art is in the balance: use external knowledge, but never become dependent on it. In this article I show what the research says, what an in-house developer and a contractor really cost, and how to decide which one you need when.

In brief

• IT contracting (team extension, or staff augmentation) means an external expert works inside your team, under your direction.
• Without a strong internal team you can't make use of external knowledge either: research shows you can only build on what you already have a foundation for.
• Without external experts the team narrows: in a classic MIT study, the performance of long-standing development teams declined as their external professional contacts dropped.
• The biggest mistake is dependency: if key knowledge lives only in outsiders' heads, you are no longer in control of your own systems.
• For financial services firms, DORA has made this a regulatory requirement: every critical external relationship needs an exit strategy and a transition period.

The wrong question: contractor or employee?

As a leader, and now as a supplier, I keep hearing the same debate. One camp says employees are the safe choice, contractors are expensive and leave. The other says in-house teams are slow and rigid, while contractors can start right away. Both are right, and both are wrong, because each wants one instead of the other.

The way I see it, the two don't replace each other, they complement each other. The internal team provides continuity, business knowledge and accountability. The external expert brings what the internal team simply can't see: how five other companies solved the same problem, what worked and what didn't. In a few years, a contractor sees more systems, more teams and more mistakes than an in-house developer sees in a decade at one company.

The question isn't employee or contractor. It's how the two strengthen each other, and who holds the keys.

What is IT contracting, and how does it differ from outsourcing?

The terms often get mixed up, yet the difference matters, because you get something different and accountability sits somewhere else. The market uses several names for the same thing: IT contracting, team extension, staff augmentation, resource provision, and in older usage body leasing.

This article is about the first two: when to build your own team, when to bring in contractors, and how the two should work together. I wrote separately about outsourcing models for testing: when to outsource software testing.

Why you need a strong internal team

Because someone has to own your systems. The internal team knows the business, the history (why something was built the way it was), the reasons behind decisions and how the company works. They carry the knowledge forward when a project ends and the outsiders move on.

There is a less obvious reason too. In 1990, Cohen and Levinthal introduced the concept of absorptive capacity: an organisation can only recognise, assimilate and apply external knowledge if it has its own related knowledge base. According to their research this capacity is cumulative, it is built through continuous investment, and if you stop investing in a fast-moving field, it is very hard to regain later.

In practice this means that even the best external expert is only worth as much to you as your internal team can understand, ask for and absorb. Without an internal team, the contractor's knowledge walks out the door with them.

Why you need external experts too: the narrowing trap

This is my personal conviction: if no outside knowledge reaches a team for years, it narrows. It repeats the same solutions because they once worked. It doesn't notice that the market now does things differently. "This is how we've always done it" isn't a sign of stability, it's a sign of closing in.

Research has described this too. At MIT, Ralph Katz studied 50 R&D project groups whose members had worked together for anywhere from a few months to nearly 13 years. The best performance came from teams with an average tenure of 2 to 4 years. In teams that had stayed unchanged for more than 5 years, performance declined, and at the same time their contact with the outside professional community dropped significantly. The author himself notes that the data came from a single organisation, but the finding has been widely cited ever since.

The external expert breaks this cycle. They bring not just capacity but fresh patterns, lessons from other companies and an outsider's questions: "why do you do it this way?" That is often uncomfortable, and that's exactly what makes it valuable.

The other extreme: becoming dependent on outsiders

The opposite direction is just as dangerous. A system is developed by outsiders for years, the internal team keeps shrinking, the documentation keeps thinning, and one day you realise there is no one in-house who can explain how your own core system works. At that point you are no longer in charge, your supplier is. In pricing, in scheduling and in every decision.

The warning signs:

• only an outsider can speak meaningfully about a critical system;
• development decisions are made by outsiders, and the internal team just signs off;
• there is no up-to-date documentation, the knowledge lives in people's heads;
• a single contractor leaving would stall development for weeks;
• the internal team has no time or opportunity to learn from the outsiders.

For financial services firms this is no longer just a business question but a regulatory one. The DORA regulation requires documented exit strategies for external ICT service providers, and for contracts supporting critical or important functions, a mandatory adequate transition period during which the firm can move to another provider or an in-house solution (DORA Articles 28 and 30). It also requires contracts to cover the provider's participation in the financial entity's ICT security awareness programmes. In other words, the regulator is saying it too: use external knowledge, but don't become dependent on it.

What does an in-house developer really cost compared with a contractor?

The most common mistake is comparing a contractor's day rate with an employee's monthly gross salary. That's comparing apples and oranges. The real cost of an employee includes employer contributions (in Hungary the social contribution tax is 13 percent in 2026), recruitment, onboarding, equipment, training, and the fact that a year has far fewer productive days than working days.

A simple estimate: a year has roughly 250 working days. For an employee, you need to subtract annual leave (in Hungary the Labour Code gives 20 days of base leave plus additional days by age), sick leave, training and internal admin. Realistically, that leaves 200 to 210 productive days. Divide the employee's full annual cost by that number and you get a much fairer comparison with a contractor's day rate.

The other factor is availability. According to the Hungarian Central Statistical Office (KSH), in 2024, 6.2 percent of Hungarian enterprises recruited or tried to recruit ICT specialists, and 3.5 percent had difficulty filling those vacancies. From these two figures it follows that more than half of the recruiting companies struggled to find the right person. This share has fallen in recent years, but the market for senior, specialist profiles is still tight.

So cost alone doesn't settle the question. What settles it is how long you need the role, what kind of knowledge it involves, and how critical it is that this knowledge stays with you. The cost of missing roles is the topic of another article too: why a missing BA costs more than having one.

Which one should you choose, and when?

Knowledge loss is especially dangerous with legacy systems; I wrote about it in detail here: why legacy modernisation projects fail.

How to keep the balance

There is no universal ratio, and I don't think the percentage is the point anyway. But a few rules work every time:

• Every critical system needs an internal owner who can take over the work if needed.
• Keep the architect, product owner and tech lead roles in-house. Outsiders can propose, but the decision is yours.
• Make knowledge transfer part of the contract, not an afterthought: documentation, joint work, code reviews.
• Pair outsiders with insiders. That way knowledge isn't just handed over, it gets embedded.
• Use the outside perspective: ask your contractor how others do it. It's free and worth a lot.
• Refresh from time to time: an outsider who stays for years gradually becomes an insider, and the fresh perspective fades.

Checklist: is your internal and external team mix healthy?

• Does every critical system have at least one internal person who knows it in depth?
• Are architecture and product decisions made by insiders?
• Is there up-to-date documentation a new person could learn from?
• Could you survive a key contractor leaving tomorrow without serious disruption?
• Do your contracts include knowledge transfer and a transition period?
• Does external expertise regularly come into your team?
• Does your internal team learn from the outsiders, or just work next to them?
• Do you compare employee and contractor costs based on full annual cost and productive days?

What we do differently at FrontX

• We only provide senior specialists who can contribute meaningfully from the first week.
• Our team members have worked at financial services firms and large enterprises, so you don't need to explain the context to them.
• We treat knowledge transfer and documentation as part of the job, not an extra. Our goal is to make your internal team stronger, not dependent.
• We work in developer, business analyst, tester and systems analyst roles alongside your internal team, following your processes.
• Details on our IT team augmentation and contracting page.

If you'd like to think through where an external expert would strengthen your team, and how to keep the knowledge with you, we're happy to help: book a free consultation.

If you are a senior specialist and want to work on projects where your knowledge matters and you get to share it, see our open positions.

Frequently asked questions

What is IT contracting?

IT contracting (team extension, staff augmentation) means an external specialist works within the client's team, under the client's direction and processes, typically billed by day rate. Direction of the work and accountability for the outcome stay with the client; the contractor is responsible for professional quality.

What is the difference between IT contracting and outsourcing?

With contracting, you direct the work and the external specialist is part of your team. With outsourcing, a supplier independently delivers a predefined outcome using its own methods and is accountable for it. Contracting is more flexible; outsourcing works better for well-defined tasks.

Is it worth hiring a contractor instead of an in-house developer?

For short-term, deadline-driven or specialist work it often is, because you don't pay for recruitment, holidays or idle time. For long-term, key roles you need your own people, because the knowledge has to stay with the company. The best results come from combining the two.

How do I compare the cost of a contractor and an employee?

Don't compare monthly gross salary with the day rate. Calculate the employee's full annual cost (salary, employer contributions, benefits, recruitment, equipment, training) and divide it by the number of productive days, typically around 200 to 210. Compare that figure with the contractor's day rate.

How can we avoid becoming dependent on an external team?

Give every critical system an internal owner, keep architecture and product decisions in-house, make knowledge transfer and documentation part of the contract, and pair outsiders with insiders. For financial services firms, DORA also requires an exit strategy and a transition period.

What does DORA require when bringing in external IT experts?

DORA requires financial entities to manage the risks of external ICT service providers, including concentration risk, and to have documented exit strategies. Contracts supporting critical or important functions must include an adequate transition period, during which the firm can switch to another provider or an in-house solution.

László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Insurance, Head of Development and Data Warehouse at Groupama Insurance, and Operations Director and board member at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services. LinkedIn profile