For a long stretch, the dream of DevOps freelancing was simple: a laptop, a reliable connection and clients you would never need to meet. Many of us built careers on exactly that. Lately, though, something has shifted. More remote DevOps freelancers are deliberately putting in-person time back into their working lives, not because clients demand it, but because they have noticed what a purely screen-based existence was quietly costing them. This is a look at that trend, told partly through the experience of one composite freelancer, and at what it means for anyone working independently today.
Meet Arjun, who had not left his desk in months
Arjun is fictional, but his story will sound familiar. He spent several years as a contract platform engineer, handling infrastructure as code, pipelines and the occasional late-night firefight for a rotating set of clients. Everything happened through tickets, chat and video calls. He was good at it, and the work paid well.
Then, gradually, it started to feel flat. He was learning new tools mostly through recorded courses and short videos at double speed. Client relationships ended the moment a contract closed. His skills were current on paper, but he noticed he was slower than he used to be at diagnosing problems in unfamiliar environments. He had been consuming expertise second-hand for so long that he had stopped stretching it in real time alongside other people.
What changed things was small. A client asked whether he could come in for two days at the start of a migration project. He nearly declined. He went, and it reset how he thought about the whole job.
The kickoff that changed the engagement
On the first morning, Arjun sat with the client’s operations lead and watched a routine deployment from start to finish. Within an hour he had spotted three things that never appeared in the project brief: a manual approval step held up by one person’s calendar, an environment that drifted from production in subtle ways, and a long-standing workaround nobody remembered the reason for. None of it was secret. It simply was not visible from a video call.
By the second afternoon, he and two of the client’s engineers were pairing at a whiteboard, sketching the target architecture with marker pens and arguing cheerfully about naming. The rest of the contract ran remotely, as planned. But every remote call afterwards was easier, faster and more honest, because they had already worked through a problem side by side. Freelancers who think carefully about earning trust with a brand-new client often find that a short on-site start does more for that trust than weeks of polished status updates.
The broader trend: selective presence
Arjun’s story reflects a pattern many independent engineers describe. Nobody is abandoning remote work; the flexibility is too valuable. What is emerging instead is selective presence: choosing a few moments where being physically in the room has outsized value, and protecting remote focus time for everything else. In conversations with freelancers, the moments that come up again and again are:
- Project kickoffs, where seeing the real workflow saves weeks of misunderstanding.
- Hands-on workshops and labs, where you work on unfamiliar tools with an instructor and peers, rather than watching someone else do it.
- Critical cutovers, where sitting with the client during a migration or launch builds confidence on both sides.
- Handover sessions, where walking the client’s team through a system in person makes the knowledge stick.
- Local tech meetups and build nights, where you solve something live instead of scrolling through other people’s demos.
Why doing beats watching for skill maintenance
The skill side of this trend is underrated. Freelancers are responsible for their own development, and the easiest path is passive: subscribe to channels, bookmark tutorials, skim release notes. That kind of input feels like progress. It rarely produces the reflexes clients pay for, such as calmly reading an unfamiliar cluster’s logs, or making a judgement call about a risky change with incomplete information.
Hands-on sessions in a physical room force those reflexes. You get stuck in front of someone. You have to explain your reasoning out loud. You see how another engineer approaches the same problem differently. Arjun now aims for one live workshop or lab session every couple of months, choosing topics just beyond his current comfort zone. He describes the difference simply: videos tell him what is possible, while workshops show him what he can actually do.
Finding the right rooms
Location shapes what is available. Freelancers in large tech cities have more options, but even smaller towns usually have coworking spaces that host build nights or skill sessions. In Bengaluru, for example, people looking for something live often browse Bangalore Orbit’s city event listings, which cover tech and developer meetups and hands-on workshops as well as concerts and comedy nights. The point is not any particular source; it is building the habit of checking what is happening nearby rather than defaulting to another recorded session.
The human side
There is a quieter benefit too. Freelancing can be isolating, and long stretches of solo screen time wear people down in ways that are easy to miss until they are serious. Arjun noticed he was more energised after days spent working alongside others, even when the work itself was hard. He also found that the clients he had met in person were far more likely to call him back for the next project. Many of the lessons drawn from successful independent engineers come back to this: relationships built face to face tend to outlast the contract that started them.
What clients say they notice
The view from the other side of the table is revealing. Engineering managers who hire contractors often say the freelancers who visit early ask better questions for the rest of the engagement. They refer to people by name, understand which system is fragile and which team is overloaded, and pitch changes in a way that fits the organisation’s real habits. A few days in the building gives the contractor context that no onboarding document captures. Clients also tend to remember who sat with their team during a stressful cutover at midnight. That memory frequently turns into the next referral, sometimes years later, when a former colleague moves to a new company and needs help.
Making in-person time work financially
Presence costs something, whether in travel, time away from billable work or event fees. Freelancers who make it sustainable tend to treat it as an investment with a clear purpose rather than a vague good intention. A few practical habits help:
- Write on-site days into proposals explicitly, with travel costs agreed upfront, rather than absorbing them quietly.
- Cluster visits so one trip covers a kickoff and a local meetup or workshop.
- Choose live learning sessions that map to the services you sell, so the skill pays back quickly.
- Keep a short note after each in-person day listing what you learned that you could not have learned remotely. Over time, that list makes the case for you.
Where this is heading
It would be easy to frame this as a reversal, but it is better understood as a correction. Remote work solved real problems for independent engineers, and it is not going anywhere. What freelancers are rediscovering is that some kinds of learning and trust are built most efficiently in person, with hands on keyboards and markers on whiteboards. The independents who thrive over the next few years will likely be those who know when to log off, show up, and do the work alongside the people who depend on it.
Arjun still works from home most weeks. He just no longer pretends that the screen can do everything.
