Remote Work Does Not Mean Always Available. Here Is How to Set That Expectation.

by Arif Ikhsanudin, Backend Developer

The assumption that remote workers are always reachable is one of the most corrosive dynamics in contractor relationships. Setting the expectation clearly is easier than managing the consequences of not doing it.

Where the Assumption Comes From

For most of the history of professional work, "available" meant "in the office." The end of the workday was visible and shared. Nobody expected a call at 10pm because everyone could see that the person had left hours ago.

Remote work removed those visual cues. And in the absence of visible signals, some clients default to an assumption of constant availability. Not because they are unreasonable — but because they have no other signal.

The phone is in your pocket. You are online. The message was delivered. Why wouldn't you respond?

This logic is common. The contractor who does not actively correct it will find themselves managing client expectations reactively, constantly, and exhaustingly.

The Cost of Not Setting the Expectation

When availability expectations are never established:

  • The client sends messages at 9pm and expects the same response time they got at 2pm.
  • When the contractor does not respond, the client fills the gap with worry or frustration.
  • The contractor starts feeling obligated to respond at all hours, which erodes the quality of both the work and the rest.
  • Eventually, either the contractor's behavior becomes inconsistent (sometimes responding fast, sometimes not) or they respond consistently at all hours and set an unsustainable standard.

None of this is the client's fault. They are operating without information.

When and How to Set It

The right moment is early — ideally during or immediately after the kickoff conversation. This does not require a formal declaration. A brief, practical note works:

"A quick operational note: I work [timezone], typically [start time] to [end time]. Messages that come in outside those hours I'll pick up the next morning. If something genuinely urgent comes up, [specific channel or phone] is the fastest way to reach me."

This is professional. It gives the client what they need to know. It sets up a response expectation that both parties can rely on. And it signals that you have worked with clients before and know how to operate this relationship.

Reinforcing Through Behavior, Not Words

Setting the expectation once is necessary but not sufficient. Behavior confirms or contradicts the stated expectation.

If you say you do not respond outside business hours but then respond to a Saturday message at 8pm, you have overridden your own expectation. The client will note that Saturday messages work.

The most effective way to manage availability is through consistency. Respond within your stated window reliably. Do not respond outside it unless it is genuinely urgent and you have said it is. Predictable behavior creates predictable expectations.

You do not need to explain why you are not responding at 11pm. You just need to not respond at 11pm, consistently.

Handling Clients Who Push Against It

Some clients will test the expectation — often not deliberately, just through the habits of their own work style. They work late, they send messages when things occur to them, and they might express frustration when the response comes the next morning.

The response to this is calm and consistent, not defensive:

"I saw your message from last night — here is what I think." Then continue as normal.

If a client explicitly pushes back on your working hours, a brief conversation usually resolves it: "I want to make sure we're aligned on how communication works so nothing falls through the cracks. I'm focused and fully responsive during [hours] — does that work for how your team operates?"

Most clients who hear this framed as a communication quality question respond well.

The Long Game

The contractor who is always available is not more productive. They are more depleted. Depleted contractors make worse decisions, write worse code, and eventually burn out or become resentful. None of that is good for the client.

A rested, boundaried contractor doing four focused hours of work is more valuable than an always-on contractor doing ten scattered ones.

You are not less committed to a client because you have working hours. You are more capable of delivering good work because of them.

Scale Your Backend - Need an Experienced Backend Developer?

We provide backend engineers who join your team as contractors to help build, improve, and scale your backend systems.

We focus on clean backend design, clear documentation, and systems that remain reliable as products grow. Our goal is to strengthen your team and deliver backend systems that are easy to operate and maintain.

We work from our own development environments and support teams across US, EU, and APAC timezones. Our workflow emphasizes documentation and asynchronous collaboration to keep development efficient and focused.

  • Production Backend Experience. Experience building and maintaining backend systems, APIs, and databases used in production.
  • Scalable Architecture. Design backend systems that stay reliable as your product and traffic grow.
  • Contractor Friendly. Flexible engagement for short projects, long-term support, or extra help during releases.
  • Focus on Backend Reliability. Improve API performance, database stability, and overall backend reliability.
  • Documentation-Driven Development. Development guided by clear documentation so teams stay aligned and work efficiently.
  • Domain-Driven Design. Design backend systems around real business processes and product needs.

Tell us about your project

Our offices

  • Copenhagen
    1 Carlsberg Gate
    1260, København, Denmark
  • Magelang
    12 Jalan Bligo
    56485, Magelang, Indonesia

More articles

The Difference Between Continuous Integration and Continuous Delivery Most Teams Blur

CI and CD are not a single acronym — they are two distinct disciplines with different goals, failure modes, and organizational requirements. Conflating them explains why most pipelines deliver neither well.

Read more

Optimistic Locking in Hibernate — @Version, Retry Strategies, and Conflict Resolution

Concurrent updates to the same entity without coordination produce lost updates — the last write wins and intermediate changes are silently discarded. Optimistic locking detects this at commit time. Here is how it works and how to handle the conflicts it surfaces.

Read more

Environment Variables in Docker Compose Without the Confusion

Docker Compose has multiple overlapping mechanisms for environment variables — .env files, environment blocks, env_file, shell variables — and they interact in ways that trip people up. Understanding the precedence order removes the guessing.

Read more

Supercell and Nokia Pay Nordic Rates — Helsinki Startups Cannot Compete on Salary Alone

Helsinki's anchor employers have set a compensation floor that most startups can't match. The teams still shipping have stopped trying to win on that ground.

Read more