Offshore vs Nearshore vs Onshore

Almost every disappointing distributed engagement can be traced back to a mismatch between how much real-time collaboration the work needed and how much the arrangement provided. Cost gets the attention because it is on the invoice. Overlap decides the outcome.

The mechanism is latency, and it compounds. In a same-hours team an ambiguous requirement costs a five minute conversation. With a few hours of overlap it costs a message and a wait, usually resolved the same session. With very little overlap it costs a day, and worse, the engineer has to decide whether to guess and continue or stop and wait. Both choices are bad. Guessing produces work that may need redoing. Stopping produces idle capacity you are paying for. Now multiply that by every clarification, every code review and every design decision in a sprint, and you can see why a supplier’s hourly rate is a poor predictor of what a project will cost.

The honest response is to measure the work rather than argue about the model. Look at a recent fortnight of your own team’s activity and count how many times someone needed an answer from someone else before they could continue. If that number is high, the work is collaboration-dense and distance will be expensive. If it is low, because the specifications are clear, the interfaces are defined and people work independently for days at a time, distance costs much less than the folklore suggests.

Overlap is also something you buy rather than something you are given. A properly run offshore engagement agrees a specific core window in writing and staffs to it, which usually means someone shifting their working day. That is a real cost to real people and it should be acknowledged rather than assumed. Ask a prospective supplier what the overlap will be, who specifically will be working it, and whether they are being paid to shift their hours. Vague answers about flexibility here are the single most reliable predictor of a difficult engagement.

Follow-the-sun deserves a mention because it is often promised and rarely delivered. The idea that work progresses overnight and returns to you finished is achievable, but only with a deliberate handover: written status, clearly bounded tasks that do not need mid-flight decisions, and a rule about what to do when a blocker appears outside the window. Without those, overnight work produces a queue of questions waiting for you in the morning, which is not the same thing at all.

We are not going to attach numbers to regions, because published figures for this move constantly, vary enormously by specialism and seniority, and are mostly quoted by people with an interest in the comparison. What is stable and worth understanding is the structure.

A supplier’s price is built from a labour market, an operating cost base, and a margin. Different countries have different inputs into all three: what an experienced engineer expects to earn, what the local cost of employment and operation is, and how competitive the local market for that skill happens to be. That is the entire mechanism behind geographic cost differences. It is not a discount and it is not a quality signal, it is the arithmetic of a different economy.

What buyers routinely leave out is the coordination cost, which increases with distance and lands on their own organisation rather than the invoice. Time spent writing specifications that would have been a conversation. Decisions made in a scheduled window rather than when the question arose. Review cycles that take a day instead of an hour. Management attention on the relationship. Occasional travel. And rework, which is the expensive one, because work built on a guessed interpretation is paid for twice: once to build it and once to correct it.

This is why total cost frequently favours nearshore even when the headline rate does not, and it is why a well-run offshore engagement can be genuinely economical while a badly run one is more expensive than staying home. The variable is not the country, it is whether the coordination discipline exists. A buyer with written specifications, a defined overlap, decisive product ownership and asynchronous review habits pays very little coordination tax. A buyer whose requirements live in conversations pays an enormous one.

The other cost that gets omitted is churn on the supplier side. Continuity is worth a great deal, because an engineer who has been on your product for a year is dramatically more effective on it than one who arrived last month, and that is true in every geography. Where a market is hot and mobile, retention becomes part of the cost calculation whether or not anyone mentions it. Ask any supplier, anywhere, how long their engineers stay. It is a more informative question than the rate.

Some of the axes in this decision are preferences you can trade off. These are not. If a legal or regulatory constraint applies, it decides the matter, and the only useful thing to do is establish it before you shortlist suppliers rather than after.

Start with jurisdiction and contracting. When both parties sit in the same country, the governing law is obvious, dispute resolution is familiar and your counsel already knows the position. Across borders, governing law and jurisdiction have to be chosen explicitly, and it is worth being realistic about enforcement: a clause naming your own courts is comforting, but pursuing a remedy against an entity whose assets are elsewhere is slow and expensive in practice. Nearshore inside a shared legal framework sits between the two and is usually much simpler than a distant jurisdiction. Whichever you choose, settle governing law, dispute resolution, intellectual property assignment and confidentiality in writing at the start, and make sure the IP assignment reaches the individual engineers rather than stopping at the supplier entity.

Data protection is the constraint most often discovered late. If personal data is involved, you need to know where it will be processed, under what transfer mechanism, by which parties acting in which roles, and what evidence you can produce when someone asks. Under UK and European rules this is a documented arrangement rather than an assumption, and transfers outside the relevant area require specific safeguards. This is designable for distant offshore, and it is genuinely simpler where the supplier sits inside the same regulatory area. What it is not is something to work out after the engineers have started.

Then there are the absolute constraints. Security clearance is national and cannot be obtained by a supplier who is not eligible for it. Some regulated work, some public sector work and some defence-adjacent work carries residency requirements for the individuals performing it. Some customer contracts specify where their data may be processed and by whom, which means your own client can determine your sourcing decision. Some procurement policies simply require domestic suppliers. Each of these ends the discussion, and no engineering argument moves any of them.

The practical advice is unglamorous and saves a great deal of time. Before you compare suppliers, ask your own legal, security and procurement people three questions: are there restrictions on where our data may be processed, are there restrictions on where the people doing the work may be located, and do any of our own customer contracts impose either. If the answers are yes, you have an onshore decision and you can stop reading comparisons. If they are no, you have a genuine choice and the other axes decide it.

Onshore is frequently presented in this category of article as the expensive default that clever buyers move away from. That framing is wrong often enough to be worth correcting at length.

The strongest case is work that is genuinely high-bandwidth. Early product discovery, where the requirement is being invented rather than implemented, moves at the speed of conversation. A team finding its shape, a founder and an engineer iterating daily, a turnaround where a set of decisions must be made together and quickly: all of these are collaboration-dense in the way described earlier, and distance taxes every interaction. Buying proximity for that phase and reconsidering later is a perfectly rational sequence, and much better than committing to a distributed structure during the phase that suits it least.

The second case is constraint-driven and already covered: clearance, residency, regulated processing, procurement policy, customer contracts. Where those apply, onshore is not a preference, it is the requirement.

The third is the one buyers admit to least readily. Some organisations do not have, and are not going to develop, the written culture that distributed work depends on. Requirements live in conversations. Decisions are made in the corridor and never recorded. Nobody writes a specification because everyone already knows. That can be a perfectly effective way to run a co-located team, and it is fatal at distance, because the mechanism that carried the shared understanding does not survive the trip. If that describes your organisation and you are not planning to change it, buying proximity is a wiser use of money than buying a rate and then discovering the dependency.

The fourth is short, intense engagements. A week of stakeholder workshops, a technical due diligence exercise, an architecture assessment that requires sitting with the people who operate the system: these are dense, brief and in-person by nature. The fixed cost of setting up a distributed working arrangement is not recovered over a few weeks, and the value of being in the room is at its highest in exactly this kind of work.

The honest counterweight is that onshore does not confer quality. A local supplier can be poor, and proximity forgives sloppy process rather than preventing it, which is why co-located projects still fail regularly. Onshore buys you overlap, jurisdictional simplicity and the ability to be in a room. It does not buy you engineering judgement, and it should be assessed on the same evidence you would demand of anyone.

Nearshore rarely wins arguments because it is nobody’s favourite story. It is not the cheapest structure available and it is not the closest. What it very often is, is the best total outcome, and it deserves to be evaluated on that basis rather than dismissed as a compromise.

The overlap argument is the core of it. A few hours of difference leaves a large shared working day, and that is enough for everything that matters: a standup people actually attend, same-day code review, a question answered while the person asking still has the context loaded. The compounding latency described earlier largely disappears, and with it most of the coordination tax. You are paying a different cost base without paying much of the distance penalty.

Travel is the second argument and it is underrated. A short flight makes in-person time practical: a week of onboarding at the start, a planning workshop each quarter, someone flying in when a hard problem needs a room. Distributed relationships are considerably more robust when people have met, and periodic in-person contact is one of the few reliable ways to keep a supplier relationship from becoming purely transactional. If that trip is a short hop rather than a long-haul expedition, it will actually happen.

Legal and regulatory alignment is the third. Where the nearby country sits inside the same regulatory area or a closely aligned one, data protection arrangements are simpler, contracting is more familiar, and enforcement is more realistic. This is a genuine reduction in risk and in legal cost, and it is worth something even when nobody has priced it.

The fourth is cultural and operational proximity: overlapping holidays, similar business norms, shared regional context, comparable expectations about how disagreement and escalation work. None of these is decisive on its own and collectively they remove a great deal of friction you would otherwise only notice when it appeared.

The honest caveat is that nearshore is not automatic. A small time difference tempts people to skip the working agreement entirely, and then the engagement gets the disadvantages of distribution with none of the discipline that makes distribution work. The core overlap, the written decisions, the clear ownership of priorities and the escalation path all still need agreeing. Nearshore makes distributed delivery easier. It does not make it free.

If you have established that no constraint blocks it and your work is not collaboration-dense, offshore is a strong option and the widest talent pool available. What follows is what it actually requires, stated as conditions rather than reassurances, because the difference between a good offshore engagement and an expensive one is almost entirely structural.

Agree a specific core overlap in writing, name who works it, and treat it as a commitment rather than an aspiration. Two to four hours of genuine shared time is enough for a great deal if it is protected and used deliberately: decisions first, review second, general conversation last. What does not work is a vague promise of availability that erodes as soon as delivery pressure arrives.

Make the written artefacts real. Requirements written down rather than described. Architecture decisions recorded with their reasoning, because the reasoning is the part that expires last. Acceptance criteria that someone eight hours away can read without needing to ask what was meant. This is the substitution that distance demands, and organisations that resist it are choosing to fail slowly.

Structure the work so it does not stall waiting for you. Clear interfaces, tasks bounded so they can be completed without a mid-flight decision, and an explicit rule for what an engineer does when they hit a blocker outside the overlap window. If the answer is that they wait, you are paying for idle capacity every time it happens.

Have a decisive owner on your side, and be honest about their availability. The single most common cause of offshore failure is not the supplier, it is a client-side decision-maker who cannot respond within the cycle the arrangement requires. If your product owner answers questions within two days, and the overlap is short, you have built a system in which nothing moves faster than a week.

Design the legal and data position properly, and design continuity too: who holds context if a key engineer leaves, what documentation exists, and what your position would be if the engagement ended next month. Your repositories, your cloud accounts and your IP should be yours throughout, in every geography, so that ending an engagement means a supplier stops working rather than something needing to be untangled.

And if you read that list and recognise that your organisation does not work that way and will not start, take the finding seriously. Offshore is not a cheaper version of the same thing, it is a different operating model with a different discipline. Choosing it for the cost base while running it like a co-located team produces rework, latency and frustration that exceed any difference in rate. If that is your situation, buy nearshore or onshore and spend the money on delivery instead of on a lesson.

Changing sourcing model partway through is common, and it is usually triggered by a coordination problem rather than a capability one. It is worth knowing what each move involves before you make it in frustration.

Moving from offshore to nearshore or onshore is usually a response to latency. Decisions are taking too long, review cycles are stretching, and the roadmap keeps slipping in ways nobody can point to a cause for. Before you move, do one diagnostic, because it frequently changes the answer. Establish whether the problem is the distance or the discipline. If your requirements are thin, your product owner is slow to respond and there is no agreed overlap window, you will export the same problems to a closer supplier and be surprised when they persist. If the specifications are good, the decisions are prompt and the work still stalls on overlap, the distance is genuinely the constraint and moving is the right call. The cost of the move is knowledge transfer: whoever holds the context has to hand it over, deliberately and in writing, with an overlap period where both parties are present.

Moving from onshore or nearshore to offshore is normally driven by cost or by talent scarcity. The work is not in changing supplier, it is in changing how your organisation operates. Write down what has been carried in conversation. Establish an overlap window and protect it. Define acceptance criteria that survive being read by someone who was not in the meeting. Get the data protection and IP position designed before anyone starts rather than after. Organisations that do this preparation first tend to succeed. Organisations that swap the supplier and expect their existing habits to carry over tend to conclude, wrongly, that offshore does not work.

A frequently sensible middle move is to split the work by its collaboration density rather than switching wholesale. Keep the discovery, the product shaping and the high-bandwidth work close, and place the well-specified, independently deliverable work further away. This is not indecision, it is matching each part of the work to a structure that suits it. The condition is a clean interface between the two, agreed explicitly, so the split follows a real boundary in the system rather than an arbitrary line through it.

Whichever direction you move, protect three things during the transition. Your repositories, cloud accounts and IP should already be yours, so that changing supplier means changing who commits rather than recovering assets from someone. Documentation should be current before the outgoing party leaves, not promised afterwards. And run a genuine overlap period, paid, with both parties present, because a handover document written by someone already working their notice is worth considerably less than a fortnight of the two teams working together.

One last point, since it is the version of this question we are asked most often. If an engagement has gone badly at distance, find out whether the model was wrong or whether it was run badly before you conclude anything about geography. Unclear requirements, an absent decision-maker and no agreed overlap will sink an engagement in any country. Fixing those is cheaper than a supplier change, and if the model still does not fit afterwards, you will at least be moving for a reason you can name.