Working With a China-Based Development Team: Time Zones, Handover and What Actually Breaks
Most offshore projects do not fail because the team cannot code. They fail because decisions take four days to travel and nobody noticed the delay compounding. This is a description of how the gap actually behaves, and the working model that contains it.
A Chengdu team and a client in Frankfurt or Toronto are usually described as having a "time-zone problem". That framing is misleading. A six or seven hour offset is a fixed, predictable cost: it removes the overlap window to roughly two or three hours a day, and everything else follows from whether the project is designed for that window or pretends it does not exist.
The offset is predictable; the latency is not
The expensive part is not the missing hours. It is the decisions that get queued behind them. A developer who needs a ruling on how a discount should be applied, and cannot get it until tomorrow morning, does not stop working — they pick the most plausible interpretation and continue. If that interpretation is wrong, the cost is not one day; it is the day plus the rework plus everything built on top of the wrong assumption in the meantime.
This is why two projects with identical scope, identical team size and identical offsets can end up three weeks apart. The difference is usually how many decisions were allowed to sit overnight.
Symptom one: the Monday decision queue
If the client reviews work weekly, every open question acquires a seven-day cost instead of a one-day cost. A project with fifteen open questions does not lose fifteen days; it loses fifteen weeks of serialised waiting, compressed only by whoever is willing to make a call without asking. The fix is unglamorous: a written question log with an owner and a date, reviewed daily on the client side, and a standing rule about which decisions the delivery team is authorised to make alone.
Symptom two: the specification that only exists in chat
Conversations in a messaging tool feel faster than documents, and for clarification they are. The problem is that a decision made in a thread has no address. Three weeks later, when someone asks why the invoice rounds the way it does, the answer is somewhere in a scrollback that nobody will search. Every project we run keeps a decision list in a single document: date, question, decision, who decided. It takes a minute per entry and it is the difference between a maintainable system and an archaeology project.
A working model that survives the gap
None of this is novel, which is precisely the point. The model below is what we actually operate; it is not a methodology brand.
- Overlap first. The two to three hours where both sides are awake are for decisions, not for status. Status goes in writing, asynchronously, before the call.
- One page per week. What was finished, what is next, what is blocked and on whom. Written by the delivery lead, not assembled by a tool.
- A question log with dates. Every open item has an owner and the date it was raised. Anything older than three working days gets raised explicitly rather than silently absorbed.
- A staging environment from week one. Reviewing work in a browser beats reviewing it in a screenshot, and it removes the "it works on the developer machine" class of argument.
- Written acceptance criteria per milestone. If it is not written, it will be argued about at delivery.
The measure of a healthy offshore project is not how many hours overlap. It is how few decisions are waiting when the overlap starts.
Handover: what "done" should include
A system is only as maintainable as the handover package. Teams optimise for the demo, because the demo is what gets accepted, and then the client discovers in year two that nobody can change the pricing engine without the original developer. The list below is what we treat as part of delivery rather than an optional extra.
- Source code in a repository the client owns, with commit history — not a zip file.
- A deployment runbook: how to build, where configuration lives, how to roll back.
- A data dictionary for the tables that carry business meaning, including the fields that look obvious and are not.
- The decision log referenced above, handed over as project documentation.
- A short recorded walkthrough per module for whoever inherits the system.
- Named access to every third-party account used by the product, in the client\u2019s name rather than the vendor\u2019s.
The last item is the one most often missed and the hardest to recover. If the payment gateway, the SMS provider or the app store listing is registered under the vendor\u2019s account, the client does not fully own the product regardless of what the contract says.
Questions worth asking before signing
| Question | What a weak answer sounds like |
|---|---|
| Who makes decisions when we disagree? | "We will discuss it" — with no named person and no tie-break rule. |
| What happens if a milestone slips? | A vague promise about "extra effort" rather than a stated consequence. |
| Who owns the code and the accounts? | Anything other than "you do, from day one". |
| How do you handle a change request mid-sprint? | A new quote for every small change, or free changes with no scope boundary. |
| What does handover include? | A list that stops at "source code". |
What this means in practice
A China-based team is a reasonable choice for a European or North American business when the work is specifiable, the decisions can be documented, and someone on the client side is willing to own the question log. It is a poor choice when the requirement is genuinely unknown and the project needs to be discovered through daily whiteboard sessions with the whole team in one room. Neither of those is a criticism of the location; they are different operating models, and confusing them is what produces the stories about offshore projects that "went wrong".
Questions we are asked
How many hours of overlap should we expect with a team in China?
Chengdu is UTC+8. Against Central Europe that leaves roughly two to three usable hours in the European morning; against North America the overlap is late evening in China, which is why we schedule calls in the client\u2019s working hours and keep written status separate from calls.
Can the team work in English?
Yes. Written communication, documentation and code comments are in English. Calls are held in English or Chinese depending on the client; for Chinese-owned businesses outside China we usually run calls in Chinese and keep the written record in English so it stays usable by local staff and advisers.
What happens if we want to take development in-house later?
The repository, deployment runbook, data dictionary and decision log are handed over as part of delivery, and we run a walkthrough with the incoming team. There is no separate unlock fee for the code you paid to have written.
