Four hours of overlap: what changes versus an offshore team
Summary:
- The overlap advantage is about decision latency, not hourly rate.
- Multi-step clarifications are where a twelve-hour gap compounds.
- Documentation helps with anticipated questions, not with the expensive ones.
- Asking a team to shift its whole day removes the advantage it was hired for.
A CTO asked us a fair question: his current offshore team costs less per hour, so why would he pay more for a team in Mexico?
The honest answer is that for some work he should not. For his work, he should. The difference comes down to one variable that almost never appears in a comparison spreadsheet.
Decision latency
Every project generates questions that only the client can answer. What should happen when a customer has two active subscriptions? Should this field be required? Which of these two behaviors is correct?
With no overlap, that question is asked at the end of the vendor's day, read at the start of the client's day, answered, and read the next morning by the vendor. One clarification, one day.
The cost is not that day. It is what happens when the answer produces another question.
| Clarification steps | No overlap | Full overlap |
|---|---|---|
| One question | 1 day | Minutes |
| Question, answer, follow-up | 2 days | Under an hour |
| A real conversation with four exchanges | 4 days | One call |
Most meaningful product questions are not single-exchange. They are conversations. And a conversation stretched across four days is not a conversation: it is four separate context switches for everyone involved.
Where offshore genuinely wins
It is worth being fair about this, because the answer is not always the same.
Offshore works well when the work is specified in advance and self-contained: porting a known system, building against a stable and documented interface, well-defined maintenance. In those cases the question rate is low and the cost per hour dominates.
Offshore struggles when requirements are still being discovered, which is the normal condition of building something new. There the question rate is high, and every question costs a day.
The practical test: how many decisions do you expect to make during this project? If the answer is few, optimize for rate. If the answer is many, optimize for latency.
The debugging case
There is one scenario where the difference is not incremental but categorical: a production incident.
When something is broken and the cause is unclear, the work is inherently conversational. Someone looks at logs, someone else knows what changed yesterday, someone else understands the business rule that is being violated. That investigation either happens live or it takes days.
For a client whose system carries real transactions, this alone can justify the arrangement regardless of what the hourly comparison says.
Frequently asked questions
Is offshore always worse than nearshore?
No. For well-specified, self-contained work with stable requirements, offshore can be excellent and less expensive. The overlap advantage matters most when requirements are still being discovered, which describes most product work but not all of it.
How much does a twelve-hour delay actually cost?
One question costs a day. The compounding is what hurts: if answering question one reveals question two, a two-step clarification takes two days with no overlap and twenty minutes with it.
Can you fix low overlap with better documentation?
Partially, and it is worth doing regardless. But documentation answers questions someone anticipated. The expensive delays come from questions nobody knew to ask, and those need a conversation.
Does the team need to work US hours?
Not if the overlap is natural. Asking a team to shift their entire day to match a client is a retention problem waiting to happen, and it removes the main advantage of being in a nearby time zone in the first place.
What about incident response outside overlap hours?
That is a separate arrangement with its own rotation and compensation, not something to solve implicitly by hoping someone is awake. If the system needs coverage beyond business hours, that has to be designed and paid for.
How to compare properly
If you want a comparison that reflects reality rather than rate cards, estimate three numbers.
- Expected decisions per week. How many times will someone need an answer only your side can give?
- Average exchanges per decision. One if your specs are unusually complete. Two or three in normal conditions.
- Cost of a blocked day. Not just the idle hours: the schedule slip and the context switching.
Multiply those and compare against the rate difference. For teams building something genuinely new, the latency cost usually exceeds the rate savings by a wide margin. For teams executing a known plan, it does not.
That is the entire argument. It is narrower than most nearshore marketing suggests, and it holds up better because of it.
What overlap does not fix
Being in a convenient time zone solves latency. It does not solve any of these, and pretending otherwise sets up a disappointment.
| Problem | What actually fixes it |
|---|---|
| Unclear requirements | Discovery work and written assumptions. Fast answers to the wrong questions still produce the wrong software. |
| A client with no available decision-maker | Nothing technical. If the person who can decide is unavailable, the time zone is irrelevant. |
| Skill mismatch | Hiring correctly. Proximity does not compensate for a team that has not built this kind of system before. |
| Scope that keeps growing | A written change process. Overlap just lets scope grow faster. |
A note on cultural distance
It gets mentioned in nearshore marketing and it is usually overstated. What matters in practice is narrower: shared business norms about deadlines, directness in raising problems, and comfort disagreeing with a client.
That last one is worth naming. A team that will not tell you your idea has a flaw is expensive regardless of where it sits. It is a hiring and culture question rather than a geography question, and it deserves to be evaluated directly instead of assumed from a map.
A practical way to decide
Rather than choosing a model in the abstract, split the work. Most companies have both kinds of project running at once.
Send the well-specified, low-question work wherever the rate is best. Keep the discovery-heavy, decision-dense work close, where a question costs minutes instead of days. Companies that do this stop having the nearshore-versus-offshore argument entirely, because it turns out to have been the wrong question.