When to hire a Drupal contractor instead of growing the team

You've got more Drupal work than the team can comfortably handle. The instinct, almost always, is to hire. And sometimes that's the right call.

But it's worth thinking the question through properly before you put a job ad up. Hiring is a much bigger commitment than it feels in the moment, and a contractor is sometimes the better answer for the agency, for the client, and for the work.

When hiring is the right call

Hiring is the right answer when the demand is genuinely sustained.

Not a busy quarter. Not a pipeline that looks healthy because two big projects happened to land at the same time. Real, predictable Drupal work you can see twelve months in advance. If you're confident the work will still be there in a year, it probably makes sense to look at a permanent hire.

It's also right when you want the institutional knowledge to live inside the team. There are projects where the value isn't just delivery, it's the developer becoming part of how the agency thinks about Drupal: writing internal documentation, mentoring more junior people, sitting in on pitches, contributing to estimates. A contractor can do good work, but they won't do that.

And if the role is junior or mid-level, where developing someone is part of the point, hiring is almost always right. You're not just buying delivery. You're investing in the next senior developer on the team.

Reality check: Most agencies hire because the work feels overwhelming this month, not because they've sat down and forecast Drupal demand for the next year. That's a recipe for over-hiring during busy stretches and carrying the cost through quiet ones.

When a contractor is the right call

A contractor wins when the demand is real but the certainty isn't.

You've got six months of solid work ahead but you don't quite trust the picture beyond that. Hiring someone permanent is a multi-quarter commitment with a salary that doesn't flex. A contractor stops costing you money the moment the work stops.

It also wins when you need a specialism your team doesn't need full-time:

• Headless and decoupled work
• Major Drupal version upgrades (D7 to D11, D9 to D11)
• Complex content migrations
• A particular module ecosystem you don't usually touch

You don't need that capability on the team year-round. You need it for this project.

Speed matters too. Hiring a senior Drupal developer takes three to six months between writing the brief, screening, interviewing, notice periods, and onboarding. If the work is in front of you now, that's not a real option.

There's a cost-flexibility argument worth being honest about. A day rate looks expensive next to a salary on a spreadsheet, but the comparison isn't like-for-like. The day rate covers a busy stretch only. The salary keeps being paid through the quiet ones.

Reality check: Plenty of agencies have learned the hard way that a permanent hire who turned out to be needed for nine months out of twelve was more expensive than a contractor would have been.

And finally, there's the work that's interesting but isn't strategic enough to anchor a permanent role around. A one-off integration. A migration. A site rebuild for a client who'll then stay on a much smaller maintenance retainer. Worth doing, not worth hiring around.

The grey zone

The honest answer for most agencies is "we always have Drupal work", and that's where it gets harder.

The question isn't really is there work? It's is the work predictable enough to staff against? You can be busy and still not have a pipeline you'd bet a permanent salary on.

The other trap a few agencies fall into is the "we'll convert them later" plan. Bring in a contractor for six months, the thinking goes, and if it works out we'll offer them a permanent role.

It almost never happens. The kind of person who'd take a salary cut to come permanent for the culture is rare, and most contractors who've built a contracting business aren't looking to undo that. If you're hiring on the assumption you'll convert them, you're really just hiring at a much higher rate than you needed to.

Sometimes the honest answer is both. Get a contractor in to cover the work you can see, while you recruit properly for the role you actually need long-term. That's a perfectly sensible plan, and one I'd usually recommend over either extreme.

What to look for in a contractor

If you've decided a contractor is the right call, the screening matters. A few things worth checking for:

Senior enough that you're not managing them

The whole point is to add capacity, not work. If the contractor needs hand-holding through technical decisions, you've hired the wrong person. A senior contractor should be able to take a brief, ask the right questions up front, and come back with the work done.

Comfortable in agency workflows

Working through a PM, taking briefings, accepting that the client relationship belongs to the agency. Plenty of good Drupal developers have only ever worked direct-to-client, and the agency context is genuinely different. A direct-to-client developer who's never had to brief through a PM can be a difficult fit.

Outside-IR35-compatible

For UK readers, worth confirming early so the contracts conversation is smooth. Most experienced contractors will already know what their setup looks like and what your standard paperwork can accommodate.

References from other agencies

Not just direct clients. The dynamics of being a contractor inside an agency are different enough that "they did good work for a non-agency client" doesn't tell you what you need to know. Ask whether they've slotted into another agency's process and how it went.

A quick decision aid

If you're sat with a hiring decision in front of you, the honest test is something like this:

• Can you forecast the work twelve months out with confidence? 
  If yes, hire. If no, lean contractor.
• Is the value in the work itself, or in the person being part of the team? 
  If team, hire. If work, lean contractor.
• Do you need someone in three months, or this month? 
  If three months, you have time to hire. If this month, only a contractor is realistic.
• Is the work general Drupal, or a specialism? 
  If general, either works. If specialism, lean contractor.

Most decisions land cleanly on one side once you actually run them through. The ones that don't are usually the cases where both is the answer.