MSP vs in-house IT team: how to actually decide

Start with coverage, not cost

The first question is not what each option costs. It is how many hours a week your technology genuinely needs to be watched, and what happens during the hours nobody is watching.

A single in-house engineer gives you roughly forty hours of coverage a week, minus annual leave, sickness, training and the time they spend in meetings. Realistically that is around thirty hours of productive coverage across a 168-hour week. If a domain controller fails at nine on a Friday evening, or ransomware begins encrypting at three on a Sunday morning, the coverage question has already been answered whether or not anyone planned for it.

This is the single largest structural difference between the two models, and it is the one most frequently left out of the spreadsheet.

The cost comparison people usually get wrong

The common mistake is comparing a managed services fee against an engineer's salary. Those are not comparable numbers. The fair comparison includes everything the salary line hides:

• Employer taxes, pension contributions, insurance and benefits, which typically add 20 to 30 per cent on top of salary
• Recruitment cost, and the vacancy period while the role sits unfilled
• Training, certification and the vendor exams needed to stay current
• Tooling: monitoring, remote access, patching, backup, endpoint protection and ticketing all carry per-seat licences that an MSP is already paying at scale
• Cover for holiday, sickness and departure, which for a team of one means either no cover or a retained third party anyway
• Management overhead: somebody has to set direction, review work and hold the vendor relationships

Run properly, that comparison often narrows considerably, and for organisations under roughly 150 users it usually favours the managed model. Above that, an internal team starts to make economic sense, though rarely on its own.

What in-house genuinely does better

There are real advantages to employing your own people, and any provider who tells you otherwise is selling rather than advising.

Institutional knowledge is the big one. Someone who has been in your business for five years knows which application the finance team cannot work without at month end, which director will not tolerate a password reset prompt, and why that one server has never been touched. That context is genuinely hard to transfer.

Presence matters too. Physical hands on site, informal corridor conversations, and being in the room when a business decision with technology implications is being made are all easier with an employee. And for organisations doing genuinely bespoke engineering work, that capability generally belongs in house.

Risk concentration cuts both ways

A one or two-person IT team is a concentration risk that organisations consistently underestimate. If that person leaves, is unwell, or simply goes on holiday during an incident, the capability leaves with them. Documentation is usually thinner than everyone assumes, because writing it down is the task that gets deferred when there is a queue.

The mirror-image risk with a provider is dependency: if the relationship ends badly, you need your documentation, credentials and configuration to come back with you. That is a contractual question, and it is worth settling before you sign rather than during an exit. Ask directly who owns the documentation and how it is handed over.

The co-managed middle ground

In practice, the fastest-growing arrangement is neither pure model. Co-managed IT keeps an internal team for business-facing work, project delivery and institutional knowledge, and layers a provider underneath for after-hours coverage, specialist security work and the repetitive operational load that burns internal staff out.

The internal team stops spending its week on patching, backup verification and password resets, and starts spending it on work that requires knowing your business. The provider handles the parts that benefit from scale and round-the-clock staffing. Both sides do what they are structurally better at.

A short set of questions worth answering honestly

If the answers make you uncomfortable, that discomfort is the useful output. It usually points at a specific gap rather than a wholesale change of model.

• How many hours a week does our technology actually need to be monitored?
• What happens today if our IT person is unavailable for two weeks?
• When did we last test a restore, and who witnessed it?
• Which of our current IT work genuinely requires knowing our business, and which is generic?
• If we outsourced tomorrow, could we get our documentation and credentials back in a week?