When to hire a freelance DevOps or SRE (and when not to)
Signs your team needs a freelance DevOps or SRE, which tasks to outsource, when it isn't worth it and how to avoid depending on one person.
By Víctor Piles TemporalSRE and systems engineerPublished on Updated on 7 min read
Many small development teams reach the same point: the application works, customers are using it, and deployments, servers and backups have been put together as they went along. Nobody has time to sort it out, and hiring someone full time just for that seems excessive. That’s where a freelance DevOps or SRE fits in. But not always: there are cases where it isn’t worth it, and it’s best to know before you hire.
In short: a freelance DevOps or SRE makes sense when infrastructure is holding the team back (manual deployments, unexplained outages, a server only one person understands) but there isn’t enough work for a permanent role. It isn’t worth it if you need an immediate human response at any hour without paying for on-call cover, or if the real problem is the product, not the infrastructure. The engagement should leave everything documented and in code so you don’t depend on anyone.
What does a DevOps or SRE engineer do in a small team?
In a large company these are different roles: DevOps focuses on how software is built and deployed, and SRE (Site Reliability Engineering) on making the production service reliable and measurable. In a team of five or ten people, the same person usually covers both:
- Automated deployments: shipping a release should be a repeatable process (CI/CD), not an SSH session with your fingers crossed.
- Infrastructure as code: servers, networks and services described in versioned files (Terraform, Ansible, Docker Compose), not configured by hand.
- Containers: packaging the application with Docker so it behaves the same on a laptop, in testing and in production.
- Monitoring and alerting: knowing something is wrong before a customer tells you.
- Backups and recovery: having a plan to bring the service back up, and having tested it.
Signs you need one
If you recognise yourselves in two or three of these situations, your infrastructure is already costing more than it seems:
- Deploying is scary and gets done at night or on a Friday “just in case”.
- There’s a server nobody dares to restart or update.
- Only one person knows how production is set up, and it isn’t documented.
- Outages are discovered by customers, not by an alert.
- Developers spend hours wrestling with servers instead of with the product.
- You don’t know whether the database backups can be restored, because it has never been tested.
When it isn’t worth it
A freelancer isn’t the answer to everything, and it’s better to say so plainly:
- If you need a human response around the clock, every day of the year. Automated monitoring can run at any hour, but one person can’t guarantee that someone will answer at three in the morning every night. For that you need a team working in shifts or on-call cover agreed in writing. In my case, automated monitoring is continuous and the human response is next business day, during business hours, including with SRE as a service.
- If the workload is full time and permanent. If there’s forty hours a week of infrastructure work for years to come, you’re probably better off hiring someone in-house. A freelancer can help you get things in order and define the role.
- If the problem isn’t infrastructure. An application that’s slow because of badly written queries or an architecture that doesn’t scale won’t be fixed by adding servers. It’s worth diagnosing that first.
| Situation | Option that usually fits |
|---|---|
| Messy infrastructure, small team, no need for night-time on-call | SRE as a service, a fixed project or a bank of hours |
| Constant, full-time infrastructure work | An in-house hire (a freelancer can prepare the ground) |
| Critical service with an immediate human response at any hour | A team with on-call shifts, or on-call cover contracted separately |
| You only need someone to look after one or two servers | SRE as a service, Standard plan |
How to set up the engagement
The healthiest way to work with an external engineer is around specific goals, with deliverables that stay in your company:
- Initial assessment. An inventory of what you have: servers, services, access, backups, domains, certificates. The result is a list of risks ordered by priority.
- First high-impact improvements. Usually verified backups, basic monitoring and an automated deployment. These give the most peace of mind for the least effort.
- Turning what’s done by hand into code. Infrastructure described in a repository of yours, with its README, so any engineer can understand it.
- Monthly fee or bank of hours. Once things are in order, the workload drops a lot: updates, alert review, improvements through tickets and a report every month.
What to require so you don’t depend on one person
The biggest risk of outsourcing infrastructure is that the knowledge stays in the outsider’s head. Always ask for:
- Everything to live in your repositories and accounts, not the contractor’s. Credentials go in a company password manager.
- Documentation on how to deploy, restore and scale, written for someone who wasn’t there.
- Standard tools (Docker, Terraform, Ansible, GitHub Actions or GitLab CI) rather than home-made scripts that only their author understands.
- Revocable access, with the engineer’s own accounts, never the shared administrator account.
With that in place, if tomorrow you change engineer or hire someone in-house, the handover is a matter of days.
I’ve been on both sides: as CTO of startups, deciding what infrastructure to build with a small team, and auditing other companies’ infrastructure from the outside. Both lead me to the same conclusion: what’s in code and documented can be handed over without depending on anyone.
On the SRE as a service page I explain how I work on a monthly fee, and in examples you can see a monthly report and an audit extract with fictitious data. If backups are what worries you, start with the guide on how to check that your backups work, and if your application lives on a server nobody looks after, the one on what server maintenance should include. Want to tell me how your setup works? Book a free 20-minute call.
Frequently asked questions
Is DevOps the same as a system administrator?
They overlap a lot. The classic system administrator looks after servers and services; the DevOps approach adds automation, infrastructure as code and continuous deployment. In a small team the line is blurred, and what matters is that the work ends up automated and documented.
Can a freelancer work with my current cloud provider?
Yes. The work is the same on AWS, Azure, Google Cloud, Hetzner, OVH or your own servers. What is worth checking is that the accounts are in the company’s name and not an individual’s.
Do I need Kubernetes?
For most small teams, no. A few servers with Docker Compose, automated deployment and good monitoring cover many applications with far less complexity. Kubernetes makes sense when there are many services, a lot of variable traffic or a team that already knows it.
How long does it take to sort out an infrastructure?
It depends on how many services there are and what state they’re in. That’s why the first step is the assessment: with the inventory in front of you, each phase can be estimated instead of giving a figure blind.
References
- Google: Site Reliability Engineering, chapter “Embracing Risk”, on availability targets and error budgets.
- Google: Site Reliability Engineering, chapter “Eliminating Toil”, on the manual, repetitive work worth automating.
