Why Fixed-Scope DevOps Beats Retainers (and What Happens at Day 90)
A retainer pays for hours. A fixed-scope engagement pays for a finished thing, and it ends on a date you can put in a calendar.
Executive brief
- Fixed-scope DevOps consulting means one defined outcome, a set window (usually 90 days) and a price agreed before work starts. A retainer buys a block of someone's time and leaves the outcome open.
- Retainers drift because nobody owns a finish line. The consultant earns the same whether your pipeline is fixed in week three or week thirty.
- A paid pilot lets you test a consultant on real work in your real environment before you sign up for anything bigger. It's the cheapest due diligence you can buy.
- At day 90 you should hold working infrastructure in your own repos, a runbook, a recorded walkthrough and a before/after comparison against the baseline. Then you choose: stop, scope a new project, or run it yourselves.
- Fixed scope isn't right for everything. On-call cover, open-ended research and problems nobody understands yet fit other models better.
- Stonetusker Systems runs paid pilots and 90-day fixed-scope engagements for SaaS, fintech, healthcare, IoT and embedded teams. Billing is by milestone, with no retainer.
What fixed-scope DevOps consulting actually means
Fixed-scope work starts with a sentence you can check. "Every service deploys from a pipeline, with rollback, in under fifteen minutes." Or "our Yocto builds are reproducible and run in CI on every merge." The engagement exists to make that sentence true, by a date, for a price both sides signed.
Three things are fixed: the outcome, the calendar and the price. Tools, sequencing and the exact hours are left flexible on purpose, because a consultant who can pick the fastest route to the outcome shouldn't be punished for finding it.
A retainer fixes something else. It fixes the input, say 80 hours a month, and hopes the output shows up. Nothing wrong with that as a product. It's just a different product, and it gets sold as though it were the same thing.
Can you describe the finished state of your DevOps problem in two sentences that a stranger could verify? If you can't, you aren't ready to buy fixed scope, and you probably aren't getting much from your retainer either.
How retainers go wrong
Most retainers start well. The first month is full of quick wins because the low-hanging problems are obvious. By month four the list of obvious problems is gone, the work turns into tickets, and the monthly review turns into a report about hours.
The pattern I keep running into has a few parts:
- The consultant is paid the same whether the deployment pipeline is finished in week three or week thirty. There's no reason to hurry and a mild reason not to.
- Work drifts toward whatever is loudest this week. Fires beat foundations every time, so the foundation never gets built.
- Knowledge lives in one person's head. When they rotate off, it goes with them.
- Ending it feels awkward, so nobody does.
- Hours logged, dashboards touched, meetings attended. None of it is an outcome.
None of this requires a bad consultant. It's what the incentive produces when the contract measures time.
Name the last three things your retainer consultant finished. Not worked on, finished. Could a new hire find them, read them and use them without asking anyone?
Fixed scope vs retainer, side by side
| Question | Fixed-scope engagement | Monthly retainer |
|---|---|---|
| What you buy | A defined outcome with acceptance checks | A block of hours or a named engineer's time |
| Who carries overrun risk | The consultant, inside the agreed scope | You. More hours means a bigger bill |
| How progress is measured | Milestones accepted or not accepted | Hours delivered, tickets closed |
| Knowledge transfer | A deliverable in its own right, before the end date | Optional, and usually deferred |
| End date | Written into the contract | None. Someone has to cancel |
| Best suited to | A known problem with a describable finish | Ongoing operations, on-call, unpredictable small requests |
| Typical failure | Scope written too loosely at the start | Slow drift with nothing clearly finished |
The fixed-scope failure is worth taking seriously, because it's real. If the scope document is vague, you get a fixed price for an argument. Most of the effort in a good engagement goes into the first two weeks of writing the scope down properly, and that effort is not wasted on either side.
Why start with a paid pilot
A free proof of concept sounds generous, and it usually isn't useful. Neither side has anything at stake, so it gets the leftover attention of a busy person and produces a demo that runs on the consultant's laptop.
A paid pilot is a small, real piece of the larger work, done in your repositories and your cloud accounts, and billed like the real thing. Because money changes hands, both sides take it seriously. You get to see how the consultant handles access requests, how they write pull requests, whether they ask good questions in week one or only agreeable ones. Those signals tell you more than a discovery call ever will.
It also protects the consultant from a bad fit. If the problem turns out to be different from the one described on the sales call, better to learn that in a small, cheap piece of work than in month two of a big one.
The pilot has to stand on its own. If it ended tomorrow and you never hired the consultant again, you should still own something useful: a working pipeline stage, a reproducible build, a baseline report you can act on.
If the pilot stopped today, would you still own something your team can run without the consultant? If the honest answer is no, you've bought a demo.
If you'd like a cheap way to see where your delivery stands before any pilot conversation, the free TuskerGauge DevOps health assessment gives a first read on where the gaps are.
What a 90-day engagement looks like
Ninety days is long enough to change how a team ships and short enough that everyone stays focused. The structure below is how I run it. Phases overlap a little in practice, but the order rarely changes.
Pick one outcome
Not a theme like "improve CI/CD". A result you can check: reproducible firmware builds in CI, or production deploys with automated rollback. If you have three problems, you have three engagements, and the first one is whichever hurts most.
Measure the baseline before touching anything
Capture deployment frequency, lead time for changes, change failure rate and time to restore, the four measures the DORA research programme popularised. Rough numbers are fine. Without a starting point, day 90 becomes an opinion contest.
Split the work into milestones with acceptance checks
Each milestone gets a plain-language test: "a merge to main produces a signed artifact and deploys to staging with no manual step." Billing follows accepted milestones, which keeps both sides honest.
Build inside your repositories and accounts
Everything lands in your source control, under your ownership, from the first commit. Nothing lives on the consultant's machine or in a private repo you'll need to beg for later. Your engineers review the pull requests, which is also how they learn the system.
Hand over, then hold the day 90 review
The last two to three weeks go to hardening, documentation, a runbook and a recorded walkthrough. Then a review meeting compares the result with the baseline and settles what happens next.
What happens at day 90
This is the part most consulting pages skip, because the honest answer is that the engagement is over. That's the design.
On the last day you should have in hand:
- Working pipelines, infrastructure code and configuration in your own repositories
- A runbook written for the person who'll be on call at 3 a.m., not for the person who built it
- Short architecture decision notes explaining why things were built the way they were
- Dashboards or reports showing the same measures you captured at the start
- A recorded walkthrough, so the next hire doesn't depend on anyone's memory
- Consultant access removed and any shared credentials rotated
Then comes the review. You look at the before and after numbers, walk through what was built, and decide. There are three sensible outcomes, and none of them is a hard sell.
| Path | When it fits | What it looks like |
|---|---|---|
| Stop | The outcome was reached and your team can run it | Engagement closes. Documentation and walkthrough are yours. This is a good result, not a failed sale. |
| Scope a new project | The first result exposed the next problem, such as security scanning or a second product line | A separate engagement with its own outcome, milestones and price. Not an automatic renewal. |
| Take it in-house | You're hiring or already have platform engineers | Your team owns everything, and any follow-up help is a small, clearly bounded request. |
A fair number of clients choose the first path. That should be unremarkable. A consultant whose business depends on you never being able to run your own delivery has an incentive problem you'd want to know about.
Ask any consultant: "What does the last week of the engagement look like, and what can my team do without you on day 91?" A vague answer means the exit was never designed.
When a retainer is still the right call
I don't think retainers are always wrong. They fit when the work is genuinely continuous: on-call coverage, a steady flow of small requests you can't predict, or a platform team that needs extra capacity for a year and knows it.
They also work well after a fixed-scope project, for a small ongoing slice of time to keep things healthy. The order matters, though. Build first, with a finish line. Retain second, once there's something clear to maintain.
Fixed scope struggles when the problem isn't understood yet. If nobody can say what "done" looks like, spend a short, separate discovery phase finding out. A consultant who pushes a fixed price onto genuine unknowns is padding the number to cover the risk.
Regulated environments: the handover is evidence
In healthcare, medical devices and fintech, the shape of a contract affects your audit trail. Neither FDA 21 CFR Part 11 nor the HIPAA rules tell you how to buy consulting. But auditors do ask who changed what, who approved it and where the record is.
A milestone with an acceptance record, changes made through reviewed pull requests in your own repositories, and access that was revoked on a known date is a much cleaner story than months of hours logged against loosely defined tasks. The handover pack doubles as evidence you'd otherwise scramble to reconstruct.
For a look at how this played out on real work, see the Stonetusker success stories.
- Fixed-scope DevOps
- Paid pilot
- Milestone billing
- 90-day engagement
- DORA baseline
- Handover and runbooks
- Retainer alternatives
- Regulated delivery
Frequently asked questions
What is fixed-scope DevOps consulting?
It's consulting sold as a defined outcome, delivered in a set window for a price agreed up front. You know what "done" looks like before work begins, and payment follows accepted milestones instead of hours worked.
How is a paid pilot different from a free proof of concept?
A paid pilot is real work in your own repositories and cloud accounts, billed like the real engagement, so both sides take it seriously. A free proof of concept tends to be a demo that never touches your actual environment, which tells you very little about how the consultant works.
What do I actually get at day 90?
Working pipelines and infrastructure code in your own repositories, a runbook, short architecture notes, a recorded walkthrough and a before and after comparison against the baseline you measured at the start. Consultant access is removed and shared credentials are rotated.
Can we extend after 90 days, and what happens to the price?
You can, but an extension is a new scoped project with its own outcome, milestones and price. It's never an automatic renewal. Many teams stop at day 90 or take the work in-house, and that's a perfectly good result.
What if the scope changes halfway through?
Changes get written down and agreed before any work on them starts. Either something in the original scope is swapped out, or a new milestone is added with its own price. Scope shouldn't grow quietly, because that's how fixed-scope work turns into an open-ended retainer.
Does fixed scope work for embedded and regulated teams?
Yes, often better than open-ended arrangements. Embedded builds and regulated releases have clear, checkable outcomes such as reproducible builds or traceable change records, and milestone acceptance records fit naturally into an audit trail.
Got one DevOps problem you can describe in two sentences?
That's enough to scope a paid pilot. Tell us what a finished state looks like for your team and we'll tell you honestly whether a fixed-scope 90-day engagement fits, or whether something else would serve you better.
Scope a fixed-scope pilot with Stonetusker