{"id":4964,"date":"2026-11-09T01:15:00","date_gmt":"2026-11-09T01:15:00","guid":{"rendered":"https:\/\/www.devopsfreelancer.com\/blog\/?p=4964"},"modified":"2026-11-09T01:15:00","modified_gmt":"2026-11-09T01:15:00","slug":"revisiting-delivered-client-work","status":"publish","type":"post","link":"https:\/\/www.devopsfreelancer.com\/blog\/revisiting-delivered-client-work\/","title":{"rendered":"The Freelancer Who Went Back to Check His Old Projects"},"content":{"rendered":"

Tomas had been freelancing in DevOps for about three years when a former client emailed him on a Friday afternoon. The deployment pipeline he had built for them was failing. The reason was almost embarrassing: a token he had created during the original project had expired, and nobody on their side knew it existed. Fixing it took ten minutes. Explaining why it happened took much longer, and the client’s tone made it clear that ten minutes of work had cost him a lot of goodwill.<\/p>\n

That Friday changed how he thought about his career. Like many freelancers, he had treated each finished project as closed. The invoice was paid, the repository handed over, and his attention moved to the next contract. What he had missed is that in freelance DevOps, the work you leave behind continues to carry your name. This story is about the skill of looking after past work, and why it may be the most underrated item on a freelancer’s skill list.<\/p>\n

The hidden half of the job<\/h2>\n

Selling new engagements gets all the attention in freelance advice: positioning, rates, outreach, profiles. Far less is said about tending what you have already delivered. Yet the freelancers who earn steady repeat work are rarely the flashiest. They are the ones whose old projects still behave.<\/p>\n

Tomas started with a simple spreadsheet. Each past client got a row. Beside it he wrote what he had built, which credentials or accounts he had created, what third-party services it relied on, and the date he last looked. The honest answer in the last column was, for most rows, never. That list became his first maintenance agenda, and it taught him something about skills: knowing how to build a pipeline is one capability, but knowing how to keep it healthy after you have left is another, and clients pay differently for each.<\/p>\n

What he checked, and why<\/h2>\n

He began with the boring things, because boring things break first. Credentials with expiry dates. Certificates. Cloud accounts billed to a card that might have changed. Scheduled tasks that depended on a vendor endpoint. Each was a place where a handover had left a silent obligation, and he now recorded renewal dates in the handover notes themselves.<\/p>\n

Next came documentation. The readme he wrote at the end of one project pointed to a dashboard that the client had since moved, and to a wiki page that had been deleted in a reorganisation. For a freelancer, a dead pointer in your handover notes looks like carelessness even when the cause is entirely outside your control. Link health is one more thing that platforms can watch for you. A tool such as URLSnow<\/a> can keep a collection of the links you publish and report which ones have stopped answering, which is handy when you maintain notes for a dozen past clients.<\/p>\n

Turning follow-up into a service<\/h2>\n

The second lesson was commercial. Tomas realised that clients rarely ask for a checkup, but they are glad when someone offers one. He began sending a short message a few months after each handover, asking whether anything had drifted and offering a brief review. Some replied that everything was fine, which is a good result. Others admitted small problems they had been putting up with, and a few turned into small paid engagements.<\/p>\n

This habit also rebuilt trust. Writing on how to winning over first-time customers over the long run<\/a> stresses that reliability after delivery is what turns a one-off job into a relationship, and his own experience matched it. Clients who feel looked after recommend you without being asked.<\/p>\n

One afternoon, a client replied to his checkup message with a list of three annoyances he had never reported. None were serious, yet together they explained why the team had stopped trusting the release process. Tomas fixed them over a week, and the client later extended the contract. Nothing about that work was clever. It was simply attention paid at a moment when nobody was demanding it, and clients remember that kind of attention far longer than a discount.<\/p>\n

Keeping your own house in order<\/h2>\n

The same logic applies to a freelancer’s own assets. Tomas reviewed his portfolio site, his repositories and the demo environments he used when pitching. Several demos had been broken for months, and one described a tool version that no longer existed. He retired the ones he could not maintain rather than leave them as quiet evidence of neglect.<\/p>\n

A side effect was time. Alongside client work, many freelancers also hold a regular job or juggle several contracts, and the discipline of limiting what you maintain matters. The guidance in freelancing responsibly while holding a full-time role<\/a> makes a point that applies here too: take on only what you can look after properly. Every project you accept becomes a small standing commitment, so the number you can sustain is a real constraint.<\/p>\n

He also stopped promising that anything would last forever. Instead he wrote an honest note into each handover stating which parts needed periodic attention and roughly how often. Clients appreciated the candour, and it set a realistic expectation that systems are cared for rather than finished.<\/p>\n

Skills worth practising<\/h2>\n