What DevOps as a Service Costs — and What Drives the Number

You searched for a price. You found vendor pages that say "contact us", a few blog posts padded with ranges wide enough to be useless, and nothing you could take into a budget conversation. Frustrating — and we're about to do part of the same thing, so let's be straight about it in the first paragraph.

We sell this (Managed DevOps is one of our services) and we publish no rate card. Not out of coyness — for a reason we'll explain, and which you can judge. What we can do, and what almost nobody bothers to do, is hand you the structure of the number: the shapes providers bill in, what genuinely moves your figure up and down, what to compare it against, and how to read two quotes that look nothing alike. Do that and you'll be able to price this yourself within a range you trust, and spot the quote that's about to hurt you.

That's more useful than a number we invented for a page. It's also the only version of this post we can write without breaking our own rule about publishing figures we can't stand behind.

Why nobody quotes this publicly (and what a published number would actually mean)

A monthly DevOps fee depends on things no web page can know: how many places your software runs, how much of your release is currently done by hand, how healthy the code underneath is, and — the big one — what you need to happen when something breaks at 3 a.m.

So a published price is one of two things. Either it's padded for the worst case, in which case the straightforward client subsidises the difficult one and you're overpaying for the privilege of not having a conversation. Or it's a teaser that gets revised upward once someone actually looks, which is a sales technique rather than a price.

Our version of this: we look first, free, and we only put a number on work you've told us you want. That means a step before the price. It's a real cost to you — your time — and it's the honest trade.

The three shapes anyone charges in

Every provider you talk to is using one of these, whatever they call it. Knowing which one you're being sold is most of the battle.

1. Fixed monthly fee — for work with no finish line. Keeping software shipping, watched and healthy doesn't end, so it's priced as a recurring scope rather than a project. This is what "DevOps as a service" normally means. The right questions are what's inside the scope, what's outside it, and how you leave.

2. One fixed price and one timeline — for work with a finish line you can scope. "Build us a proper deployment pipeline for this one application." If the shape is clear enough to commit to, you should get one number, not a meter.

3. Hourly — for work with a finish line nobody can honestly scope yet. Deep unknowns in an inherited system, or a scope that will move as everyone learns. Hourly gets a bad reputation, but it's the honest answer here: padding a fixed price for unknowns means you pay for that risk whether or not it materialises.

Two traps worth naming. First, size doesn't move work into the monthly bucket — a big one-off project that can't be scoped is still hourly; only the absence of a finish line makes something monthly. Second, watch for the fourth shape wearing the first one's clothes: a "monthly retainer" that's really a bucket of hours. That's not the same product. A recurring scope means someone is accountable for an outcome every month; a bucket of hours means you've pre-purchased attention and the outcome is still yours. Both are legitimate. Being sold the second while thinking you bought the first is how month three gets tense.

What actually drives your number

Roughly in order of impact:

What you need when it breaks. The single biggest multiplier, and the one buyers under-examine. "We know before your first customer of the morning" and "a human is awake and responding at 3 a.m." are wildly different products with wildly different costs, because the second one requires enough people to make a rota. Most marketing blurs them under "around the clock" — which usually describes automated monitoring, continuously running, which is genuinely valuable and is not a person. Decide honestly what your business needs before you compare prices, or you'll compare two quotes for different things.

How much is manual today. Setup is front-loaded. If releases are currently a remembered ritual, the first months carry real build work before the steady rhythm starts. A provider whose price is flat from month one is either amortising that across the term (fine, but ask about the notice period) or hasn't looked yet.

How many moving parts. One application in one place is a different job from a dozen services, several environments, and three cloud accounts nobody has audited. Not because of hosting cost — because of the number of things that can independently break.

How healthy the software itself is. This is the one that surprises people. If the application crashes, loses data, or nobody understands the code, better deployment machinery just ships the same problems more reliably. Honest providers will tell you the repair comes first — for us that's Project Rescue — and that ops on top of a broken product is expensive precisely because it never gets quiet.

How much of the function you're handing over. Releases only, or releases plus environments plus monitoring plus the working rhythm on top? Scope is the price. Get it itemised.

How fast you change. A system shipping several times a week costs more to run than one shipping monthly, because every release is an event someone is accountable for. Shipping more is usually the goal — just know it's a cost driver and not a freebie.

Whether you have engineers. Working alongside a capable team is a different engagement from being the entire function. Cheaper isn't automatic in either direction — coordination has a cost too — but it changes the shape.

Compliance. Audit trails, evidence, named ownership, restricted access. If you're in one of those regimes, it's not a line item, it's a different service level.

What to compare it against

A monthly fee looks like a new cost sitting next to zero. It isn't — you're already paying for this function, just not on an invoice. Three real comparisons:

The full-time hire, fully loaded. Not the salary — the total: recruitment, benefits, equipment, your management time, and the structural problem that the role is genuinely full-time for the setup quarter and part-time afterwards by design. We laid that math out in you don't need a full-time DevOps hire — yet, including the cases where hiring is the right answer. Do that comparison with your own numbers, not a blog's.

Your developers' time, at their rate. Every hour a product engineer spends restarting servers and chasing deploys is infrastructure labour bought at a product-engineering price, paid for out of the feature work you actually hired them to do. Estimate those hours for one honest month. It's usually the number that ends the debate.

What the current situation already costs you. Launches that slipped. The outage a customer found before you did. The feature that sat finished for three weeks waiting for a safe evening. The holiday nobody could take. These don't appear on any invoice, which is exactly why they lose the argument to a line item that does.

How to read two quotes that aren't comparable

They never are. Normalise them on these seven, in writing, before you compare a single figure:

1. Scope, itemised. What's in, and — the question people forget — what stays your team's job.
2. Response, contractually. What's automated, what a person answers, within what window, on which days. Ignore the marketing sentence; read the commitment.
3. What's extra. Incident work beyond some threshold? Project work? Tooling licences? Onboarding or setup fees, and what deliverable is attached to them?
4. Is the cloud bill inside or outside the fee? This alone can make the cheaper-looking quote the expensive one. Get it stated.
5. Notice period, and the reason for it. Both extremes deserve a question. A long lock-in with no explanation is revenue protection; "cancel anytime" with no handover plan sounds generous until the week you use it.
6. Who owns the accounts. Cloud, repositories, domains, monitoring — in your company's name, with them invited, or the reverse? The reverse is lock-in presented as a convenience.
7. What you get handed if you leave. Documentation produced as a byproduct of the work, or promised as a future phase? Ask for an example of what they'd hand over.

The longer version of this list, with the questions that flush out the answers, is in 12 questions to ask before you hire a DevOps partner.

Pricing-specific red flags

• A price before anyone has looked at how you ship today
• Per-server or per-node pricing that quietly punishes you for growing
• "Unlimited" anything — nobody sells unlimited engineering, so it's defined somewhere you haven't read
• A fee that only makes sense if nothing ever goes wrong
• A low headline number with the actual function living in add-ons
• A setup fee with no deliverable attached to it
• Discomfort with question 4 above

How ours works

So you can hold us to the same list:

The first look — the review — is free, written, and yours to keep, including if you hand it to your own team or to another provider and never speak to us again. For ongoing work we agree a monthly scope and one monthly price up front, before the first month is billed. You can step away on 90 days' notice; there's no multi-year lock-in, and the three months exist so the handover is orderly rather than abrupt — access, documentation, and whoever picks it up next. Where work has a finish line and a clear shape, it's one fixed price and one timeline. Where it genuinely can't be estimated, it's hourly, and we'll say so rather than pad a fixed number. And we only quote work you've told us you're proceeding with — no speculative proposals for decisions you haven't made.

The trade-off we're accepting by not publishing a rate is real: some readers leave this page for one that shows a number. We think a number without your context would be a worse thing to have done.

The number you actually need first

It isn't ours. It's what your current situation costs you every month — the developer hours going into plumbing, the releases that slip, the outages you learn about from customers, the launch that moved. Almost nobody has written that down, which is why the monthly fee always looks like new spending rather than a swap.

Write it down. Then the pricing conversation with any provider, us included, becomes a comparison instead of a leap.

Our free DevOps review does the other half of that page for you: how a change reaches your customers today, every manual step, every single point of failure, and the plan we'd run — in writing, free, yours to keep. Nothing changes in your systems while we look; read access is enough. If it says you don't need us, that's what it'll say.