The async-first argument says that with good writing you need no overlap at all. We have run engagements at four hours of overlap, at ninety minutes, and briefly at none, and the argument is half right in a way that matters. Writing does replace meetings. What it does not replace is the speed at which a blocked person becomes an unblocked one, and that is the number which decides whether an engagement feels fast or slow.
The short version
The constraint is decision latency, not communication. Async writing fixes communication and leaves latency untouched.
Four hours is the practical floor for product work with unresolved questions. Two is workable for maintenance with a clear backlog.
A blocking question at zero overlap costs a full day. Two in a row cost a week of elapsed time for a day of work.
Overlap only counts if someone is actually answering during it. Reserved hours beat nominal hours.
The fix for low overlap is not more hours, it is fewer blocking questions, which is a ticket-writing problem.
The real constraint is decision latency
A developer hits a question they cannot answer alone: the design does not say what happens when the list is empty, the API returns a shape nobody documented, two requirements contradict each other. This happens several times a week on any real project, and it is not a sign of a bad developer. It is what building something that has not been built before consists of.
What matters is the time between the question being asked and being answered. With overlap, that is minutes, and the developer keeps working. Without it, the answer arrives after they have gone home, so the cost is not the ten minutes of conversation. It is the remainder of their working day.
Now compound it. Two blocking questions in sequence, which is normal because the answer to the first often creates the second, costs two days at zero overlap and under an hour at four. A week of work becomes two. Nobody was slow, and nobody could point to where the time went.
"Async writing fixes communication. It does not fix latency, and latency is what makes an engagement feel slow."
Latency is also what makes review speed a budget line rather than a courtesy, as set out in what an offshore team really costs.
How much you actually need
This depends almost entirely on how well specified the work is, and not at all on how senior anyone is. A very good engineer on an ambiguous ticket asks more questions, not fewer.
India to the US East Coast gives roughly four hours if the Indian team works into the evening, which is what we do: 13:00 to 22:00 IST puts 09:00 to 12:30 ET inside the working day at both ends. India to the UK is easier, around seven hours. India to the US West Coast is the hard one, and honest vendors will tell you it means someone works unsociable hours. The only question is who.
Our own window is four hours with New York and seven with London, which is why the offshore web development page states the hours rather than calling them flexible.
Overlap that counts, and overlap that does not
Nominal overlap is what the contract says. Real overlap is the time during which a question actually gets answered. These are frequently different numbers, and the gap is where engagements go wrong while everyone is technically compliant.
Reserve it
If your reviewer is in back-to-back meetings for the whole window, your overlap is zero regardless of the calendar.
Name one person
A question addressed to a channel is a question addressed to nobody. Name who answers, and who covers when they are away.
Front-load the window
Unblocking first, review second, status last. Status can wait a day; a blocked engineer cannot.
Where our interests differ from yours
We are in Pune, so we benefit from you believing that four hours is sufficient. It is, but the reason is that we shift our own day to create it, and any vendor telling you overlap is a non-issue is either not shifting theirs or not planning to answer during it. Ask which hours, in your timezone, and get it into the statement of work.
A named reviewer with a response target is also the single thing that most improves a paid pilot.
The better fix: need less of it
Every hour of overlap is an hour somebody works outside their normal life. It is worth buying, but it is worth buying less of. The way to do that is to reduce the number of questions that block, which is a writing problem rather than a scheduling one.
The rule in the third row is the highest-use one, and it is the hardest to adopt because it feels like tolerating interruption. In practice it converts a blocked day into a switched task, and it is the single change that makes low-overlap engagements survivable.
Fewer blocking questions is mostly a ticket-writing problem, and it is the same discipline that keeps an estimate from drifting.
What to put in the statement of work
Overlap is the term most often agreed verbally and least often written down, which is why it is the term most often disputed in month three. It costs four lines.
The last one causes more confusion than it should. Twice a year the gap between IST and both ET and GMT changes, which means a window that was four hours becomes three or five without anyone deciding to change it. Agreeing in advance which side absorbs the shift takes one sentence and prevents an annually recurring argument.
One more thing worth writing down: what happens to the window during a crunch. The honest position is that it can be extended by agreement for a defined period and then returns. The dishonest position is that it quietly extends and never returns, which is how good engagements become resented ones on both sides.
Overlap belongs in the statement of work next to the other commercial terms, which the contract checklist lists in full.
Questions people ask
Where to go next
Overlap is one of the eleven things worth pinning down on a first call. The rest are in the eleven questions that sort vendors. If you want to test the process rather than the promise, run a paid pilot and watch how fast questions actually get answered. Our own hours and the overlap they produce are on the offshore web development page.
Sources
Yogesh Jadhav
Founder of reactdevstudio. Ten years as a working full stack developer, across SaaS products and client work.
Related, Group A only
Three more on offshore work
Procurement and process posts only, scored within Group A, so a delivery reader is never handed a React internals piece.
