Hire a DevOps engineer — or skip the hire.

The reason this distinction matters more than it sounds: a hire is an ongoing commitment made to solve a problem. If the problem is finite, the commitment outlives it. You end up with a talented engineer, a deployed application, and several quarters of trying to find them enough work to justify the seat — or a departure and the institutional knowledge leaving with it.

Plenty of teams do have genuine ongoing platform work, and for them the rest of this page is a straightforward guide to hiring well. The sections below cover all four routes honestly, including the three that do not involve us.

We are not going to quote you a salary figure, and you should be sceptical of pages that do. “DevOps engineer” is not a standardised job title. The same work is advertised elsewhere as platform engineer, site reliability engineer, infrastructure engineer, cloud engineer, or build engineer — at meaningfully different seniorities and pay bands. Any single number for “the cost of a DevOps engineer” is averaging across roles that are not the same role.

What is more useful is the shape of each cost, which is stable even when the numbers are not:

• A full-time hire costs base compensation plus employer overhead, plus the recruiting effort and the vacancy period before anyone starts, plus a ramp before the first deploy ships. The cash cost is the part people plan for; the calendar cost is the part that hurts when something needs to be live this quarter.
• A contractor costs an hourly or daily rate, plus your own time scoping and reviewing. That second cost is routinely underestimated — the narrower your specification, the more of it you pay.
• An agency costs a retainer, usually with a floor. Judge it on whether you have enough genuine scope to consume the minimum, not on the rate.
• A productized service costs a fixed price for a defined outcome. It is the only one of the four where the number is knowable before you commit, because the thing being bought is a result rather than an amount of time.

The comparison worth making is not rate against rate. It is: what does the specific outcome I need cost under each route, including my own time and the delay before it exists? Finite work usually looks very different under that question than under a rate comparison.

Screen for judgement, not tool lists

A CV listing every tool in the ecosystem tells you very little — the tools are learnable and they change. What does not change is judgement about trade-offs: when managed services are worth the premium over running it yourself, when to add a layer of abstraction and when it will cost you later, and how much complexity a team your size can actually carry. Ask about a decision they now think was wrong, and why.

Questions that tend to be revealing

• Walk me through what happens between a merge and that change serving traffic. You are listening for whether they think in terms of a complete path, or a collection of tools they have configured.
• How would you set this up for a team our size? Strong candidates scale the answer down. Weak ones describe the architecture from their last, larger job.
• Tell me about an outage you handled. Look for diagnosis and what changed afterwards, not heroics.
• What would you deliberately not automate here, yet? Knowing what to leave alone is a senior skill and it is rarely faked well.
• How do you hand work over? Relevant for every route, and decisive for contract work.

Signals worth taking seriously

• Recreatable infrastructure. Can they rebuild an environment from scratch, or does it only exist because someone once clicked through a console?
• They ask about your product. Infrastructure decisions that ignore what the application does tend to be expensive in both directions.
• Clear about cost. Cloud spend is an engineering output. Someone who has never had to defend a bill has been insulated from part of the job.
• Comfortable saying “I do not know.” The surface area is enormous. Confident answers about everything are a warning, not a strength.

Two common mistakes

The first is hiring for a backlog. The work in front of you today is not the work the role will consist of in a year — if you cannot describe the second, you may be hiring to clear a queue rather than to fill a seat.

The second is hiring one person to be an entire platform team. Build, infrastructure, security, cost, observability and on-call are genuinely several jobs. One person can hold them for a while at a small company, but the expectation needs stating out loud before they start, not discovered afterwards.

You built something with AI tools and it stops at localhost

Code from Lovable, Bolt, Replit, v0, or Cursor is usually fine. What is missing is everything around it — environments, secrets, a database that persists, a domain, and a build that runs somewhere other than your laptop. That is a deployment problem, not a coding problem, and it does not recur once solved. The specifics are in the production readiness checklist.

You are moving off a platform you have outgrown

A migration has a working application on both ends and a definable finish line, which makes it an unusually poor reason to open a role and an unusually good fit for outside help. The directions that migration can take are in our comparison of Heroku alternatives.

You have a model and you need it behind an API

A trained model in a notebook is not a service. Getting to an endpoint other systems can call means packaging, provisioning, and a deploy path — one exercise, not an ongoing function. See from Jupyter notebook to production API.

A customer wants your software inside their own cloud

Enterprise buyers increasingly ask vendors to run inside the customer's account rather than a shared platform. Doing that once, properly, is a different exercise from running your own SaaS — and it rarely justifies a hire on its own. The model is explained in what BYOC actually means, and the architecture in deploying SaaS inside a customer's AWS VPC.

And one that is not on the list

If your team already has the skills and simply has no spare attention this quarter, that is not a hiring problem either. Handing one deployment to an outside provider is often cheaper than the context-switch, and it does not commit you to anything ongoing.