Contract or permanent? A short guide for infrastructure hires

The usual way to make this decision is to compare a day rate with a salary, wince, and hire permanently. That comparison answers the wrong question. The useful one is this: when the work is finished, what needs to remain inside the company?

When a contractor is the right call

The work has an end. A cloud migration, a move from Jenkins to GitLab CI, a Kubernetes upgrade you have postponed three times. Once it is done, the workload drops, and you do not want to have hired a permanent engineer for a project that no longer exists.

You need a skill for months, not years. Setting up a landing zone, passing a first ISO 27001 audit, or designing an observability stack are things an organisation does rarely. A specialist who has done it ten times will be quicker and make fewer expensive mistakes than a capable generalist doing it for the first time.

You are short on the rota right now. Somebody resigned, the permanent search will take a few months, and the remaining team cannot absorb the gap. A contractor is the difference between a stretched team and a second resignation.

When you need a permanent hire

The thing must be owned. A platform that product teams depend on needs someone who will still be there when the decisions they made start to cause problems. That is when the real learning happens, and a contractor has usually left by then.

The knowledge is the asset. If the value lies in understanding your systems, your history and your people, you want that understanding on the payroll.

You are building a team. The first two or three infrastructure hires set how the team works: how it documents, how it handles incidents, how it treats developers. That is hard to outsource.

The mistake in each direction

Hiring permanently for project work leaves you with a good engineer and not enough for them to do. They get bored and leave, usually within the year.

Using contractors for ownership leaves you with a platform nobody inside the company fully understands. It works until the contract ends, and then every change becomes a small excavation.

A sensible middle path

The two are not exclusive, and the combination is often the best answer. Bring in a contractor to do the migration while you run the permanent search properly. Make the handover part of the contract: documentation, runbooks and a few weeks of overlap with the person who will own the result.

One practical point. If you think there is any chance you will want to keep a contractor, say so before the contract starts and agree what conversion would cost. It is a much easier conversation to have at the beginning.