In-house hire vs on-demand engineering: what coverage actually costs
By the Erzon engineering team · Last updated July 13, 2026
TL;DR
- Verdict: it depends on incident load, and honestly so. Steady, weekly reliability work justifies a full-time hire. Sporadic but painful incidents favor on-demand incident engineering. Feature backlogs favor an agency. Most SMBs mix the first two.
- A senior SRE or infrastructure engineer costs roughly $180k to $300k+ fully burdened in North America, plus 2 to 4 months to hire and onboard, and one person still cannot cover 24/7 alone.
- On-demand incident engineering costs per incident or per month (Erzon: from $250 per incident, retainers from $2,500 per month) and covers you from the day you sign, but it will never know your system like an employee.
- A generalist agency is built for planned work, not pages. Good for roadmaps, wrong shape for 2 a.m.
The three options, defined
In-house hire. A full-time senior engineer, SRE, or infrastructure lead. They own reliability, learn your system deeply, and are there every day.
On-demand incident engineering. A specialist firm (this is what Erzon does) that you call when production breaks, or keep on retainer for guaranteed response. You pay for incidents and coverage, not for headcount.
Generalist agency. A dev shop engaged for projects: build the app, migrate the infrastructure, staff the team. Reliability work gets slotted into their delivery schedule.
These are not interchangeable. They differ on the two axes that matter: how fast you get real coverage, and what a year of it costs.
Side by side
| Dimension | In-house senior hire | On-demand incident engineering | Generalist agency |
|---|---|---|---|
| Annual cost | $180k to $300k+ fully burdened | Per incident (from ~$250) or retainer (from ~$2,500/mo) | Project fees or ~$10k to $30k+/mo retainer |
| Time to coverage | 2 to 4 months to hire, weeks to onboard | Days: access setup, then covered | Weeks: scoping, contracts, scheduling |
| System knowledge | Deepest, compounds over years | Shallow at first, warm on retainer | Deep on what they built, thin elsewhere |
| Incident depth | Depends on the individual hired | High: incidents are the entire practice | Variable: senior people often booked |
| Response at 3 a.m. | If on call, and one person burns out | Contractual on retainer | Rarely; next business day is typical |
| Utilization | You pay for 100%, use what you use | You pay for what happens | You pay for scheduled capacity |
| Failure modes | Wrong hire, key-person risk, churn | Onboarding tax on first incident | Incident response competes with sprints |
| Also builds features | Yes | No | Yes, it’s the core business |
The honest trade-offs
In-house is the best option past a certain scale, full stop. Nothing beats an engineer who has lived inside your system for two years. If you have enough reliability work to fill a week, every week, hire. The catch is everything before that point: a 2 to 4 month search, the risk that your first SRE hire is wrong (expensive to discover), and the arithmetic of on-call. One person cannot be awake all year; real 24/7 coverage in-house means a rotation, which means roughly three people who can each handle production alone. That is a half-million-dollar-a-year capability, entirely reasonable at 50 engineers, absurd at 8.
On-demand engineering wins on economics when incidents are sporadic. If production breaks badly four times a year, you are choosing between roughly $250k of salary and a few thousand dollars per incident. The specialist also brings something a single hire can’t: pattern exposure. Production failures cluster into a surprisingly small set of shapes (deploy gone wrong, database degradation, certificate and DNS surprises, queue backlogs), and a team that works these daily is often faster on an unfamiliar codebase than a generalist who knows the code but has seen two real outages. The honest weaknesses: first-incident onboarding costs real minutes, pure per-incident help is reactive by nature, and an outside firm will not attend your architecture reviews unless you structure a retainer that way.
Agencies are the right tool for the wrong problem here. If you need a product built or a migration executed, an agency’s shape (teams, sprints, delivery management) is exactly right. But incident response is anti-scheduled work. The agency’s strongest engineers are utilized on committed projects; your outage arrives without a statement of work. Teams that route incidents through their dev agency typically report next-business-day responses and mid-level engineers doing the diagnosis. That is not a criticism of agencies; it is a mismatch of operating model.
Which should you choose?
Hire in-house when: reliability work is genuinely continuous, you’re past roughly 10 to 15 engineers or you sell uptime contractually, and you can either staff a rotation or accept business-hours-only depth. At that scale, in-house is not just defensible, it’s correct.
Use on-demand incident engineering when: incidents are sporadic but expensive, you have no one senior in the failing domain (databases and infrastructure are the usual gaps), or you’re mid-hiring and need coverage during the 2 to 4 month gap. A retainer version makes sense when you want guaranteed response times without guaranteed salaries.
Engage an agency when: the work is planned, buildable, and schedulable. Keep incident response out of that contract, or at least read the response-time clause before you rely on it.
The common hybrid, and frankly the pattern we see most at SMB and mid-market: in-house engineers own the product and the daily operations they’re good at, with an on-demand specialist behind them for the failure classes they hit twice a year. Each covers the other’s weakness.
If you’re weighing this right now
The worst time to decide is during an outage, and that is when most teams decide. If you want a concrete basis instead: Erzon offers free triage with a first response within one business hour, and a flat quote at triage, so a single incident can tell you what on-demand coverage actually feels like before you commit to anything, including to us.
Questions on this
At what size does hiring a full-time SRE make sense?
A common rule of thumb: when reliability work would genuinely fill a week, every week. That usually means multiple production services, real traffic, and recurring incident load, often somewhere past 10 to 15 engineers or when uptime is contractually promised to customers. Before that point, a full-timer spends much of the year underloaded at a fully burdened cost of $180k to $300k or more.
Isn't on-demand help slower because they don't know our system?
There is a real onboarding cost on the first incident: access, context, architecture. Specialists offset it because production failures are strongly patterned, and a team that has seen a hundred replication or deploy failures diagnoses an unfamiliar system faster than a generalist who knows the codebase but not the failure class. A retainer removes most of the gap by keeping access and context warm.
Why not just use our existing dev agency for incidents?
Agencies are built for planned feature work: sprints, backlogs, utilization schedules. Incident response needs someone senior available now, and an agency's best people are usually committed to other clients this sprint. Agencies remain the right choice for building things, they are rarely the fast path when production is down.