The most expensive risk on a retainer is not outages. Outages are visible. The costly thing is different: a contractor who profits from finding himself work. Hours are billed, unused ones expire, and the client has neither the time nor the expertise to check whether each task was justified. Expertise is what he came for. From outside, an honest contractor is indistinguishable from a “resourceful” one: both answer fast, both send invoices on time.
The difference lives in the message history. This case isn’t about one project. It’s a line running through 9 episodes across 24 months where we talked the client out of work we would have earned on. Each episode left a trace: a tracker task or a chat message. There is not a single sum in this case, and that is the point. Money shows up here only as behavior.
Snapshot
| Client sector | digital agency (web studio) |
| Client | anonymized — Media Studio, Russia |
| Engagement | DevOps retainer, sole-proprietor to sole-proprietor contract, direct client |
| Project type | meta-case: the relationship model on a long retainer |
| Work scope | ~14 servers under support, 96 tracker tasks over the period |
| Project date | 10 Jun 2024 – 28 Feb 2026 (628 days — span of episodes) |
| Effort | monthly retainer with a minimum block; individual case episodes from 0.25h |
| Team | 3 specialists (sysadmin-engineer · engineer on point · project manager) |
| Tech stack | ISPmanager · Bitrix · MySQL/MariaDB · nginx · Zabbix · Redmine |
| Delivered | the client handed the studio its own end client on a direct contract, and recommended the studio to a third company |
The problem
The agency runs a fleet of ~14 servers: GitLab, cloud, monitoring, a control panel, and a stack of client sites, mostly Bitrix. We came in during May 2024, after their previous admin left, on a classic retainer: a minimum monthly block, unused hours expire, off-plan tasks billed on top.
The economics of a contract like this push the contractor one way. The more tasks you “find,” the bigger the invoice. The client understands this no worse than we do. The first months of any retainer go to checking who he actually hired. Below is what that check turned up, episode by episode.
9 episodes
1. The client brings in a big project himself, and we close it in 0.25 hours. June 2024. The client sets a task: work up a move to infrastructure-as-code (IaC), produce a plan and a price. Budget ready, direct request, just go and scope it. The engineer answers from practice: ISPmanager standardizes very poorly, you’d still have to install and configure it by hand. Backups, on the other hand, the panel rolls out itself. The deciding argument was time: “given the DNS propagation time, which runs for hours, there’s no real point in spending big money to invent something. By the time DNS updates, the deploy is already done.” Instead of a project: advice with no invoice, split the backup server and the production datacenter across different hosts. The client’s reply on the task: “Got it. No more questions here.” Effort booked: 0.25 hours.
2. “We’d gain pennies.” July 2024. Talk turns to pushing nginx caching harder on a client site’s Yii backend. The tuning hours would have been ours. The engineer cuts the thread himself: “this is clearly a long one and we’d gain pennies. Not worth it, I think.” Instead of caching, he hands the client’s developers application-level recommendations.
3. An invoice against ourselves. October 2024, a contract for 10 hours a month. In the monthly report: actual effort came to 4.5 hours, “underworked.” The figure isn’t pulled from the air. The sum of the tracker entries matches the chat to the quarter-hour.
4. “50 units went missing, I’ll add them next month.” A discrepancy in the accounting the studio found itself, and announced itself in the client’s chat, without waiting for a reconciliation. Hour-tracking is open at all times anyway: the studio’s bot answers an effort query right in the shared chat.
5. “No need to rush.” December 2024 – January 2025. Negotiations over a large project for the client’s own customer: a call, 2 engineers, architecture work. In January, called off, the customer couldn’t cover the budget. The studio’s reaction in chat: “no need to rush.” No pressure, no “special terms until the end of the week.”
6. Two honest price options and the right to pick the cheap one. March 2025. A client project’s dev server needs PHP 8.1, and the OS is old. The engineer lays out both paths with an honest price in hours. The fast one: a temporary panel license and a version switch, an hour of work. The right one: a new server on a supported OS plus migration, from 3 hours, a 30 GB database and 80 GB of files, “databases that size don’t load quickly.” The client picked the cheap path. The studio logged the risk (the server still has to be upgraded eventually) and did not insist.
7. “Maybe we don’t need to clean anything?” August 2025. A disk-cleanup task comes in: billable, agreed, you could just do it quietly. The engineer looks at the screenshots first: “going by the screenshots there’s almost half the space free, maybe we don’t need to clean anything?” The task didn’t happen.
8. No extra memory without a diagnosis. November 2024. The client has a reflex for a slow server: “just add memory.” The engineer stops him: “not sure that helps, without finding out the cause, what process and why it ate everything.” Adding hardware is the easiest sale in support, because you don’t have to justify it. We justify it: cause first, then hardware.
9. “Give back half the memory.” February 2026, a sales-season crisis at the end client’s store: under load the server got more resources, memory grew from 24 to 64 GB. The crisis passed, and the engineer writes on his own: “let them cut the memory back in half to 32G… if everything’s steady, let them put it back as it was.” The client pays the host less. The initiative came from the contractor, whom no one pays for it.
Timeline
| Period | Episodes |
|---|---|
| June–July 2024 | declined IaC in 0.25h; “we’d gain pennies” |
| October–November 2024 | “underworked” on the invoice; “don’t add memory without a cause” |
| December 2024 – January 2025 | “no need to rush” on the called-off negotiations |
| March 2025 | two price options, client picked the cheap one |
| August 2025 – January 2026 | “maybe we don’t need to clean anything?”; “50 units went missing, I’ll add them” |
| February 2026 | “give back half the memory” |
The episodes are spread across 24 months of ordinary work: monthly updates, incidents, and planned tasks ran between them. The line of refusals is continuous, not a one-off stunt at the start of the contract.
Results
| Metric | Value |
|---|---|
| Documented refusals of billable work | 9 over 24 months (06.2024 – 02.2026) |
| Fastest “project declined” | 0.25h — the IaC task closed with a single rationale |
| Invoice against ourselves | 4.5h on a contracted 10h/month, reported as “underworked” |
| End client handed to the studio on a direct contract | November 2024, on the agency owner’s initiative |
| Studio recommended to a third company | August 2024: “I want to recommend you here as devops” |
| Length of the relationship | 24+ months, contract renewing |
Here is how that check came out. In November 2024, the agency owner offered it himself: “we want to hand this client to you on a direct contract. Will you take it?” For the subcontracting market this is an exception. A subcontractor is usually hidden from the end client, not introduced to him directly. Earlier still, in August, the same owner recommended the studio to a company he knew as a DevOps contractor. The recommendation and the handed-over contract are the only “revenue” in this case, and it turned out larger than all the hours we refused.
Team
- Sysadmin-engineer (studio): the main task stream; author of most of the refusals in this case
- Engineer (studio): point engagements (presales, hardware and database consults)
- Anton Hersun, Xaver Pro — project manager
Choosing a DevOps contractor on retainer and want to understand who you’re actually hiring? Start the way the client in this case did: with a small check. Send us a brief or your current technical documentation. We’ll look it over, flag the bottlenecks, and come back with a fixed estimate in hours. If some part of the plan isn’t worth doing, we’ll be the first to say so. The conversation is free.