The first objection US buyers raise about a team in Kathmandu is always the clock. “They’re asleep when we’re awake.” Mostly true: Kathmandu sits at UTC+5:45, roughly ten to eleven hours ahead of the US East Coast and more for the West. The objection assumes the gap is a cost to be minimised. Structured deliberately, it is the opposite — the gap is the feature you are buying.
The inverted day
Invert the picture. You hand off at your evening — spec agreed, open questions answered, priorities clear — and log off. Kathmandu’s entire workday fits inside your night. By the time you sit down for your morning standup, the work has been implemented, reviewed, and merged. Your calendar experiences the team as an overnight build: problems go in at dusk, working code is waiting at dawn. When the handoffs are clean, each calendar day contains two workdays, and neither team attends a single meeting outside its own daylight hours.
“They’re asleep when we’re awake” turns out to describe a pipeline, not a problem. The real question is whether the delivery system is built so nothing important has to happen while both sides are awake at once.
What makes the overnight cycle actually work
Follow-the-sun fails when it is attempted with a synchronous work style and a long-distance phone bill. It works when the artefacts that normally live in meetings become written, durable, and asynchronous:
- Written specs — precise enough to implement without a clarifying call. The spec is the handoff. If it takes a conversation to interpret, the conversation happens at your evening, before the baton passes — not at 3am.
- Decision logs — every consequential choice recorded with its reasoning, so nobody on either side ever waits half a day to ask “why is it like this?”. The answer is already written down.
- Eval-gated merges — quality enforced by machinery, not by a synchronous demo. Tests, static analysis, and regression evals in CI decide whether work is done; a named engineer signs the merge. You review outcomes in the morning instead of supervising the process at midnight.
The common thread: nothing waits for a meeting. Anything that would normally block on a person being awake is turned into an artefact that works while they sleep.
The overlap window is real, and it is enough
None of this means the teams never talk. The geometry gives you a genuine daily window: US morning is Kathmandu evening. Eight in the morning in New York is quarter to six in the evening in Kathmandu in summer, quarter to seven in winter. That window carries everything that is genuinely better synchronous — the standup, a demo, an argument about a trade-off, pairing on something gnarly. It is a scheduled, protected hour or two, not an all-day channel. The discipline is deciding what belongs in the window and refusing to let everything else creep into it.
Where it fails
Honestly: not every organisation should buy this. The overnight cycle fails for teams that need real-time babysitting — where requirements are discovered by interruption, decisions are only made in meetings, and the spec is a Slack thread that changes by the hour. If your organisation cannot write things down, the time difference will faithfully return that ambiguity to you every morning as the wrong feature, built well. Follow-the-sun does not fix an undisciplined process; it invoices you for it overnight.
Nearshore’s shared-hours model is the other valid answer
Nearshore vendors sell the opposite geometry: a team in your time zone, sharing your working hours, collaborating in real time all day. That is a valid model — for a conversational work style, it is the right one. The trade is straightforward. Shared hours buy you immediacy and cost you the overnight cycle; the inverted day buys you a pipeline and costs you all-day availability. Neither is superior in the abstract; they suit different ways of working. Buy shared hours if your process runs on conversation. Buy follow-the-sun if your process runs on writing — or if you want the forcing function to make it so.
We run the same discipline with European clients, where the geometry is gentler — Kathmandu’s afternoon overlaps Europe’s morning directly. That version is written up in running a distributed team between Europe and Kathmandu; the artefacts are identical, only the clock arithmetic changes.
If you are weighing a dedicated team and the time zone is the sticking point, look at how our dedicated teams are set up to work asynchronously by default — and bring your hardest scheduling objection to a technical call, not a sales call.