Working with clients eight or nine hours away is the normal condition for a lot of freelance developers, and it goes one of two ways. Either the overlap is treated as the working relationship — in which case somebody is always up late and the arrangement quietly becomes unpleasant — or the asynchronous part is treated as the working relationship, and the time difference turns into an advantage.
The second is genuinely better for both sides, and it does not happen by default. It requires changing how progress is communicated, how questions are asked, and how decisions get made, because all three normally assume that a conversation is cheap and immediate.
This post is about those changes: what has to be different, what the overlap is actually for, and how to keep the arrangement from consuming your evenings permanently.
What actually goes wrong?#
Round-trip latency, and the way it compounds through a project.
The mechanical problem is simple. A question asked at the end of your day is answered at the end of theirs, which is the start of your next one. One unanswered question costs a day. Three sequential questions — each depending on the previous answer — cost three days, and neither party did anything wrong.
The cultural problem is worse. When answers take a day, people stop asking, and start guessing instead. Guessing produces work that has to be redone, discovered late, and the pattern repeats until somebody suggests a daily call at an hour that suits neither person.
| Pattern | Cost |
|---|---|
| A blocking question at end of day | One day |
| Three dependent questions | Three days |
| A guess that was wrong | The work plus the rework |
| A daily sync at a bad hour | Sustainable for about six weeks |
| Batched questions with options | Usually zero |
The bottom row is the whole technique, and the rest of this post is about how to get there.
The advantage is real when it works#
A client who reviews at the end of their day and finds the changes done when they return has effectively gained a shift. That is a genuine benefit of the arrangement rather than a consolation, and it is what you are protecting by structuring the work asynchronously.
How do you ask questions?#
With the options already worked out and a default you will proceed with.
This single change removes most of the latency cost. Instead of "how should permissions work?", which requires a considered reply, send the analysis: here are the two reasonable approaches, here is what each implies, I am going with the first unless you say otherwise by tomorrow.
Always include a default#
The default is what converts a blocking question into a non-blocking one. If they respond, you adjust; if they do not, you proceed and nothing was lost. It also communicates that you have thought it through, which is more reassuring than asking.
Batch the non-urgent#
Questions that do not block work should accumulate into one message rather than arriving as six notifications. One considered message gets one considered reply; six scattered ones get three replies and three that were missed.
Mark the genuinely blocking ones clearly#
Occasionally something really does stop everything — a credential you do not have, a decision only they can make. Flagging those explicitly, and separately from everything else, means the one thing that needs a fast answer gets one.
Never ask a question you can answer#
A question that a competent developer could reasonably decide is one you should decide and note. Clients are not a lookup service, and a stream of small questions transfers your work to them while also slowing everything down — which is the worst of both.
What is the overlap for?#
The things that genuinely need a conversation, and nothing else.
If you have two or three hours of overlap, that time is scarce and should be protected for what actually needs synchrony: an ambiguous requirement, a decision with trade-offs, a difficult piece of feedback, a demo where reactions matter. Using it for a status update wastes the one thing you cannot substitute.
Status does not need a call#
Written updates are better than spoken ones — they are skimmable, searchable and do not require both parties present. A call spent describing progress is a call not spent resolving the thing that is actually unclear.
Demos benefit from being live#
Watching somebody react to a feature tells you things a written response does not, particularly hesitation. That is a legitimate use of overlap and it is worth scheduling deliberately rather than letting it be squeezed by status.
Difficult conversations should be synchronous#
A scope disagreement, a missed deadline, an uncomfortable piece of feedback — these go badly in writing, where tone is ambiguous and a reply takes a day. Anything with emotional content deserves the overlap.
Keep the meeting short and prepared#
An agenda sent in advance, with the decisions needed listed, turns a scarce hour into a productive one. Arriving without one means spending the overlap working out what to discuss, which is the least valuable possible use of it.
How do you communicate progress?#
Visibly and continuously, so nobody has to ask.
The anxiety in a remote arrangement is not knowing whether anything is happening. That anxiety is what produces check-in requests, and the fix is making progress observable rather than reported — which is cheaper for both sides than any amount of reassurance.
A deploy on every push is the best status update#
When each change produces a URL, the client can look whenever they want, in their own time zone, without asking. This removes an entire category of coordination and it is the highest-value process mechanism available regardless of geography.
Write a short daily note#
Three lines at the end of your day: what got done, what is next, anything blocking. It takes two minutes, it arrives while they sleep, and it means their morning starts informed rather than with a question.
Make the work visible in the repository#
Small, frequently pushed commits with real messages let anybody technical see progress directly. It also means that if you are unavailable, the state of the work is legible without you.
Flag slippage early and in writing#
A deadline at risk should be raised as soon as you know, not at the deadline. Across time zones that is doubly true, because there is no corridor conversation to soften it and the reaction arrives a day later regardless.
How do you protect your hours?#
By setting them explicitly at the start, before there is a habit to break.
The default trajectory of an unmanaged arrangement is toward your evenings, because each individual accommodation is small and reasonable. Establishing the shape at the beginning — when it costs nothing — is far easier than renegotiating it in month three after establishing that you answer at 11pm.
State your availability in the proposal#
Working hours, overlap window, response time expectation, and what happens in a genuine emergency. Written down at the point of agreement, it is a normal professional term rather than a complaint raised later.
Meet in the middle rather than at one end#
If overlap requires somebody to be uncomfortable, alternating who takes the awkward slot is fairer and more sustainable than one party always accommodating. Most clients accept this readily when it is proposed as a principle rather than requested as a favour.
Do not answer at 11pm#
Every out-of-hours reply teaches that out-of-hours replies happen, and expectations form from behaviour rather than from stated policy. Scheduling a message to send in the morning is the same information without the precedent.
Define what an emergency actually is#
Production down, a security issue, a payment system failing. Not a design question, not a new idea. Naming the category in advance means the exception exists without expanding, and it lets you respond properly when it is genuinely warranted.
What tooling actually helps?#
Less than people hope, and the useful part is convention rather than software.
Write decisions somewhere permanent#
Anything agreed in a call needs to exist in writing afterwards, because the person who was asleep has no access to it otherwise. A short summary in a shared place is what keeps a distributed record consistent.
Use scheduled sending#
Working at your convenience and delivering at theirs removes the pressure both ways. It is a small feature in most tools and it does more for sustainable async work than any project management system.
Show times in both zones, always#
Every proposed time in a message should carry both zones explicitly. It takes a few extra characters and it prevents the recurring meeting-missed-by-an-hour, particularly around daylight saving changes when the usual offset silently shifts.
Keep the tool count low#
A client managing three tools across a time difference will use one of them, and you will not know which. One channel for conversation and one place for written decisions is enough, and adding more reduces rather than improves communication.
Record the time zone in the record itself#
A note saying a meeting is at three o'clock is ambiguous the moment somebody in another country reads it back. Writing the zone alongside every time, in shared documents as well as in messages, prevents a small recurring category of confusion that gets worse twice a year when the offsets shift independently.
What about the relationship?#
It needs deliberate attention, because none of the incidental contact exists.
In a co-located arrangement a great deal of trust is built through small interactions nobody plans. Remotely there are none of those, so what remains is the quality of the delivery and the communication — which means both have to carry more weight than they would otherwise.
Reliability substitutes for presence#
Doing what you said, when you said, is how trust is established at a distance. It matters more than it would in person, because there is no other evidence available and every missed commitment is proportionally more visible.
Occasional video helps disproportionately#
A face on a call every few weeks does something that text does not, and it makes difficult conversations easier when they arrive. It does not need to be frequent to have the effect.
Be explicit about tone in writing#
Written communication reads as more curt than intended, particularly across languages and cultures. A slightly warmer register than feels natural is usually the correct calibration, and it costs nothing.
Acknowledge receipt even when you cannot answer#
A one-line "seen this, will respond properly tomorrow" prevents a day of wondering whether the message arrived. It is the cheapest possible action and it removes a genuine anxiety on their side.
Does the time difference affect pricing?#
It should not, and it frequently does — in both directions.
There is a persistent expectation that a developer in a lower-cost location should charge less, and a corresponding temptation to compete on that. It is a poor long-term position, because it is a race with no floor and it prices the location rather than the work.
Price the outcome, not the geography#
What a client is buying is a working product delivered by somebody accountable. That has a market value determined by the result and the alternatives, and where you happen to be is not a component of it — the same argument as pricing time versus outcome.
The overlap constraint is a real cost#
If a client requires substantial synchronous availability at hours that are difficult for you, that is a genuine imposition and it belongs in the price. Framed plainly it is uncontroversial, and it usually results in the requirement being reduced rather than paid for.
Do not apologise for the arrangement#
A remote working relationship with a time difference is entirely normal and has been for years. Treating it as something requiring justification invites the client to treat it as a concession, which is the wrong footing for everything that follows.
When does it genuinely not work?#
Three situations, and recognising them early is better than discovering them slowly.
When the work requires constant collaboration#
Pair programming, a fast-moving incident response, an embedded role in a team that makes decisions in real time. These need overlap that a large time difference cannot supply, and forcing it produces a permanently strained arrangement.
When the client cannot work asynchronously#
Some organisations make every decision in meetings and cannot function otherwise. That is a legitimate way to operate and it is incompatible with a nine-hour difference, and it is better identified in the first conversation than in the second month.
When there is genuinely no overlap#
Below about an hour of shared working time, the occasional necessary conversation becomes an imposition every time. It is workable for well-defined delivery and difficult for anything requiring frequent judgement calls.
Say so during scoping#
All three are visible while scoping if you ask how decisions get made and how much synchronous time is expected. Raising the concern then is professional; discovering it in delivery is a problem — and declining is a legitimate outcome.
What does it cost?#
More writing, and a discipline about hours that has to be maintained.
Asynchronous work means writing considerably more than a co-located arrangement requires: daily notes, decision summaries, questions with worked options. That is real time, perhaps twenty minutes a day, and it is the mechanism that makes everything else function.
The honest counterweight: some things genuinely are slower this way, and pretending otherwise is how the arrangement fails. A design question that would take five minutes in person takes a day, and a project involving many small ambiguous decisions will run longer across a large time difference than it would co-located. The right response is to build that into the estimate and to structure the work so those decisions are batched — not to claim that asynchronous work has no cost, which stops being credible the first time a decision takes three days.
Every out-of-hours reply teaches that out-of-hours replies happen. Expectations form from behaviour, not from the availability you stated once.
Conclusion#
The problem is round-trip latency and the way it compounds — three dependent questions cost three days, and when answers are slow people stop asking and start guessing, which costs more. The fix is structuring the work so that almost nothing blocks on a reply.
Ask questions with the options already analysed and a stated default you will proceed with, which turns a blocking question into a non-blocking one. Batch anything non-urgent into a single considered message, flag the genuinely blocking items separately, and never ask something you could reasonably decide yourself.
Protect the overlap for what actually needs it: ambiguous requirements, decisions with trade-offs, demos where reactions matter and any conversation with emotional content. Status is better written, and a call spent on it is a call not spent on the thing that was unclear.
Make progress observable rather than reported — a deploy on every push plus a three-line note at the end of your day removes the anxiety that produces check-in requests. Then set your hours explicitly in the proposal, alternate who takes the awkward slot, and do not answer at 11pm, because behaviour sets expectations rather than policy.
Build trust through reliability, since none of the incidental contact exists, and calibrate your written tone slightly warmer than feels natural. Price the outcome rather than the geography, put a genuine overlap requirement in the number, and recognise early when the work needs constant collaboration that a large difference cannot supply. If you are considering working this way, that is how I run it.