We should declare the obvious: for most people reading this we are an offshore software development team. So take the following as what it is, an account from inside the arrangement, including the parts that are inconvenient for us.
Offshore engagements rarely fail because of skill, and almost never because of time zones on their own. They fail because of four specific things, all of which are preventable and none of which are about geography. Distance does not cause them. It removes the accidental corrections that would otherwise catch them: the overheard conversation, the desk you walk past, the question asked in a corridor. Take those away and small misunderstandings survive long enough to become expensive.
Why people do it, and where it goes wrong
The reason is usually budget, sometimes availability of particular skills, occasionally follow-the-sun coverage. Those are all legitimate and often work out. When it goes wrong, it is one of these four, in roughly this order of frequency.
- Assumed understanding. Both sides believe the requirement was clear. It was clear to each of them, differently. Nobody discovers this until a demo.
- The overnight round trip. A question that would take thirty seconds in person takes a day, and after that happens a few times, people stop asking and start guessing.
- Ownership nobody wrote down. Code, accounts, domains, credentials, all fine while things are fine.
- Scope that was never written properly, so the estimate was fiction and the argument was inevitable.
Written first, always
The single highest-value practice, and the one that most separates engagements that work from ones that do not.
Every decision of consequence gets written down, in a place both sides can search, in the same language, before anyone builds anything. Not minutes of a meeting that nobody reads. A short written statement of what was decided and why, that the other side confirms. When a call ends with agreement, someone writes what was agreed and the other party says yes or corrects it.
This feels bureaucratic for about two weeks and then it becomes the reason the project is calm. It also removes the most common failure entirely, because assumed understanding cannot survive being written down and confirmed. And a specific point about working across languages: many people write English far more precisely than they speak it under pressure on a call. Writing is not a workaround for weaker communication, it is often where the clearest thinking happens.
Overlap that actually means something
Time zones are treated as the central problem and they are not, but they do need handling deliberately rather than hopefully.
- Three or four hours of genuine overlap is enough, and more is not obviously better. What matters is that it is real, protected and predictable rather than nominally available.
- Both sides give something up. If the overlap is achieved entirely by one team working unsocial hours, it will erode within two months, and the erosion will not be announced.
- Protect it for conversation. The overlap is for the things that need discussion, not for status updates that could have been written.
- Have a rule for urgent. An agreed route that reaches someone out of hours, and a shared understanding of what genuinely qualifies. Without that, either everything is urgent or nothing is.
- Use the non-overlap deliberately. Work handed over at the end of one day and picked up at the start of another is the actual benefit of the arrangement, and it only happens if handovers are written well.
Ownership, in writing, at the start
This matters more at distance, because the practical remedies if it goes wrong are harder. Enforcing anything across borders is slow and expensive, so the protection has to be structural rather than legal.
- Repositories in your organisation, with the team given access. Not their organisation with a promise to transfer later.
- Cloud accounts in your name, paid by you, with the team having roles you granted. This is the one people concede for convenience and regret.
- Domains registered to you. Always. There is no acceptable version where a supplier holds these.
- Credentials in a shared vault you own, so revoking access is something you can do in five minutes without asking anyone.
- Written assignment of the work, whatever the local law says by default, because you should not need to know what it says by default.
- A documented handover from day one, kept current, rather than promised at the end. The value of a handover written at the end is that it does not exist.
Ask for all six in the first conversation. Any serious supplier will find it a normal question. Who owns your website covers what to check and how to recover it if you are already in trouble.
Scope, estimates and changing your mind
At distance, an unclear scope is worse than it is locally, because there is no informal correction. A local team building the wrong thing tends to find out in a corridor by Wednesday. A remote team building the wrong thing finds out at the demo, with two weeks of work behind it.
- Describe outcomes, not implementations. What a person should be able to do, and how you will know it worked.
- Insist on being told what is unclear, and treat a list of questions as good news rather than as a supplier being difficult. Silence at the start of a project is not agreement, it is usually guessing.
- Short blocks with something working at the end. Two weeks. The demo is the correction mechanism that distance removed, so it has to be frequent.
- Name one decision-maker on each side. Not a committee. Distance plus ambiguous authority is how projects stall for a fortnight without anyone noticing.
- Agree how changes are handled before there are any. Small trades within a block get swapped rather than invoiced, larger ones get a conversation. Decide this while everyone is relaxed.
Show working software every week
If you take one thing from this article, take this. A weekly demo of something you can click is worth more than every other governance mechanism combined.
Written reports can be optimistic without anyone lying, because progress is genuinely hard to describe. Software cannot be optimistic. Either the thing works or it does not, and everyone in the call can see which. A team that shows working software weekly cannot drift for long, and a team that resists doing so is telling you something now rather than in three months.
It also fixes the reporting relationship. Instead of asking whether things are on track, which invites a reassuring answer, you watch and form your own view.
Questions to ask any offshore software development team
| Ask | What you are listening for |
|---|---|
| What hours will we actually overlap, and who is adjusting to achieve that? | Whether the overlap is real and shared, or one team quietly working late until they stop. |
| Who will I speak to every week, and will it be the same person? | Continuity. A rotating cast is how context gets lost. |
| Show me a demo from a current project. | Whether weekly working software is a habit or a promise. |
| Where does the code live during the project? | Your organisation, or a transfer you have to trust. |
| What happens if I want to stop after a month? | Whether you are being sold a partnership or a lock-in. |
| How do you handle a requirement you think is wrong? | You want to hear that they push back. A team that only agrees is expensive. |
| Who else has worked on this codebase, and what happens if they leave? | Whether knowledge is documented or living in one person. |
| Can I speak to a client in a similar time zone to mine? | The specific experience of working with someone at your distance, not a generic reference. |
Ask these of us too. Twenty questions to ask a development agency has the broader list that applies to any supplier, near or far.
When local is genuinely better
Not a formality. There are cases where we would tell you to hire near you, and it costs us the work to say so.
- You need someone in the room regularly. Facilitating workshops, sitting with users, physically being where the work happens. Some projects are mostly this, and video does not substitute.
- The work is deeply tied to local regulation or institutions, where the value is knowing how things actually operate in your jurisdiction rather than what the rules say.
- Hardware, premises or physical processes are involved and someone needs to be standing next to the machine.
- Nobody on your side can own the relationship. Offshore work needs one person who reads the writing, attends the demo and decides. Without that it will drift, and no supplier can supply it for you.
- Procurement requires it, which is not a technical argument but is a real constraint and there is no point fighting it.
That fourth point is the one we would emphasise, because it is the one people miss. The single best predictor of an offshore engagement working is not the supplier's quality. It is whether one named person on the client side has the time and authority to run it. If nobody has that, the arrangement will disappoint regardless of who you hire.
Not for you if
The point of publishing this in our own words is straightforward. Everything here is true whether you hire us or someone else, and if you use it to evaluate us and decide against, the article did its job. Read how we work and then put us through the list.