This is a composite story, built from situations independent DevOps engineers describe again and again. The names are invented; the lessons are not. It follows a freelancer we will call Kavya through two similar contracts: one where she treated the final delivery as the end of the job, and one where she planned the freelance post-delivery support period as carefully as the build. The difference between the two engagements had little to do with technical skill and everything to do with what happened after go-live.
Contract one: a clean delivery that went sour
Kavya’s first client was a small online retailer with a creaking set of virtual machines and a deployment process that relied on one long shell script. Her brief was clear: containerise the application, move it onto a managed Kubernetes service, set up a CI pipeline and write documentation. The contract specified deliverables and a completion date. It said nothing about the weeks afterwards.
The build went well. She delivered on time, ran a two-hour walkthrough with the client’s sole in-house developer, shared the repository and the documentation, and sent her final invoice. Everyone was pleased.
Eleven days later, a message arrived late on a Friday evening. A certificate renewal had failed and the storefront was showing browser warnings. The in-house developer had tried a fix from the documentation, but the instructions assumed access he did not have. Kavya, now deep into another project, spent her weekend sorting it out. She did not bill for it, because the contract had no clause covering support and she did not want to sour the relationship.
Over the following month, three more requests arrived. Each was small. Each landed at an inconvenient time. By the end, the client felt the system was fragile, Kavya felt taken for granted, and a promising relationship cooled. Neither party had acted in bad faith; the after-period had simply never been designed.
What went wrong, precisely
Reviewing the engagement later, Kavya identified four specific gaps:
- No defined support window. Neither side knew whether post-delivery help was included, for how long or on what terms.
- A single-event handover. One walkthrough is not enough for someone who will operate an unfamiliar platform alone.
- Documentation untested by its reader. She had written it from her own perspective, with her own permissions.
- No scheduled follow-up. Every later contact was reactive and unplanned, which made each one feel like an emergency.
None of these were technical failures. They were planning failures, and they were all avoidable.
Contract two: designing the after-period first
A few months later, Kavya took on a similar project for a regional logistics company: migrating a set of services onto containers, introducing infrastructure as code and building a deployment pipeline. This time she started by drafting a section of the proposal titled “After go-live”, before she had written a single line of configuration.
A hypercare window written into the contract
She proposed a fixed hypercare period after cutover, with clear terms: during that window she would be reachable during agreed working hours, would respond to production issues within an agreed timeframe and would make small fixes without extra charge. After the window, further help would be billed under a separate, optional retainer. The client appreciated the clarity. Our guide to agreeing fair terms with DevOps clients covers how to raise points like this without sounding defensive.
Named people on both sides
She asked the client to name an internal owner for the new platform and a backup for when that person was away. She also named herself as primary contact and, for the hypercare window, a trusted fellow freelancer as her own backup in case she fell ill. The client’s owner joined her planning calls from the second week, so the handover started long before go-live.
Staged handover instead of a single walkthrough
Rather than one session at the end, she planned three stages. In the first, the internal owner watched her perform routine tasks. In the second, he performed them while she watched. In the third, during hypercare, he handled everything himself and only contacted her when stuck. Each stage had concrete tasks: deploying a release, rolling back, rotating a secret, scaling a service and restoring from backup.
Documentation tested by the person who would use it
She asked the internal owner to follow each runbook from his own account, with his own access, and to mark anything that did not work. Several steps that had seemed obvious to her turned out to rely on permissions he lacked. They fixed those before cutover, not on a Friday night afterwards.
Follow-up reviews booked in advance
Before go-live, she sent calendar invitations for a short series of review calls spread across the hypercare window, plus one final handover meeting on its last day. Each call had a standing agenda: what happened since the last call, any incidents or near misses, documentation gaps found and anything the owner felt unsure about. The final meeting closed hypercare formally and confirmed whether the client wanted a retainer.
She also prepared a one-page contact sheet for the client: who to message for which kind of problem, what counts as urgent, which channel to use outside working hours and what information to include in a request. It took twenty minutes to write. It removed a surprising amount of friction later, because every request that arrived already contained the logs, timestamps and context she needed.
How contract two actually played out
Cutover took place on a weekday morning. There were two minor issues in the first days: a misconfigured resource limit and a log retention setting that filled storage faster than expected. Both were raised through the agreed channel, during working hours, and fixed quickly. Neither felt like a crisis, because both sides knew exactly how to handle them.
By the middle of the window, the review calls had become brief. The internal owner was answering most of his own questions. At the final meeting, he walked Kavya through a rollback he had performed alone, and the client signed a modest retainer for quarterly reviews. That retainer later grew into two further projects. Just as tellingly, the internal owner recommended her to a peer at another firm, describing the handover as the smoothest he had experienced.
Kavya’s overall effort on contract two was not much greater than on contract one. The difference was that her after-period effort was scheduled, bounded and paid, instead of scattered, open-ended and unpaid.
Borrowing from other industries
Kavya later said the idea had clicked when a friend described planning medical treatment abroad. Services such as SurgeryPlanet, which plans treatment trips for international patients, put accommodation, airport transfers and aftercare into the itinerary alongside the procedure itself. She realised her own deliveries needed the same shape: the weeks after go-live were part of the job, not an awkward extra.
The template Kavya now uses
For every engagement, Kavya’s proposal now includes an “After go-live” section covering:
- Hypercare window length, hours of availability and response expectations.
- What is included during hypercare and what falls outside it.
- Internal owner and backup on the client side; primary and backup contact on her side.
- Handover stages and the tasks the owner must perform unaided before the window closes.
- A documentation test, carried out by the owner with their own access.
- Dates of follow-up reviews and the final handover meeting.
- Terms for optional support after hypercare ends.
She also keeps a short log during hypercare, recording each request, its cause and its fix. The log feeds into the final meeting and often reveals small improvements worth adding to the documentation.
Lessons for other freelancers
A few principles stand out from Kavya’s two contracts:
- Clarity protects the relationship. Clients rarely resent a defined support window; they resent uncertainty. Our piece on keeping scope and client expectations aligned explores this further.
- Handover is a process, not a meeting. Plan it in stages and test it with real tasks.
- Book the follow-ups before go-live. Once a project ships, both calendars fill quickly.
- Bound your availability. Hypercare with clear hours and an end date is sustainable; indefinite goodwill is not.
- Use the after-period to build trust. A calm, well-run hypercare window is one of the strongest arguments for repeat work, as discussed in our article on managing long-term client relationships as an independent engineer.
The build gets you paid once. The after-period, planned with the same care, is what gets you hired again.
