The Hidden Costs of Offshore Development

The only number you know in advance

Every offshore comparison starts with the same table. Rate here, rate there, a gap of two or three times, a total that looks like a decision already made. The rate is the one figure that is contractual and certain before anyone writes a line of code. Everything else — hours the work takes, hours that are productive, output still standing in ninety days — is an estimate, and estimates lose arguments against contracts.

A declaration of position first. East Wolf is a Bucharest studio, most of our work is for clients in Western Europe and North America, and our rates are lower than a London or Zurich firm charges for the same seniority. We have been on the receiving end of the cheap-rate comparison for twenty years. So this is not an article arguing that distributed delivery is a trap. It is about which costs the rate excludes, how to measure them with data you already hold, and where the crossover actually sits — because it is not where most rate tables put it, and it has little to do with geography.

Coordination is a tax on every hour

Communication paths grow quadratically with people. A four-person co-located team has six. Add a vendor tech lead, a delivery manager and a client-side product owner across a time boundary and you are at twenty-one, most of them mediated by ticket comments and a narrow call window. The cost is not the meetings. It is that every path is a place where intent degrades slightly, and the degradation only surfaces downstream — in code review, or in production.

On distributed teams working well, 15 to 20 percent of engineering hours go to coordination: standups, written clarifications, review cycles, re-explaining a decision made in a call someone missed. On badly matched engagements — junior team, thin domain context, wide time gap — 35 to 40 percent is ordinary, and nobody notices, because coordination hours arrive on the invoice labelled as engineering hours. No invoice has ever carried a line called re-explaining the billing model for the fourth time.

Roughly half of this tax never reaches the invoice at all. It is paid in salaried client-side time: the product manager answering questions two hours a day, the architect reviewing every pull request because nobody else will catch the mistakes. Real money, spent by the people whose attention is already the scarcest resource in the company. Budget it explicitly, or it gets spent anyway out of capacity you were counting on elsewhere.

Latency compounds along the decision chain

The number that matters is not the offset. It is the offset multiplied by the round trips a piece of work needs. At two hours, a blocking question asked at 10:00 is answered by 12:00 and the day continues. At nine hours it is answered tomorrow. A feature needing six clarifications — unremarkable for anything touching billing, permissions or a regulated workflow — carries six days of pure latency on top of three days of engineering. The engineering was never the schedule.

The compounding is worse than the arithmetic, because latency changes behaviour. When asking costs a day, engineers stop asking. They infer. A good engineer infers correctly most of the time, and when they do not, the wrong assumption has been built on for a day before anyone can see it. That is the real cost of a wide time gap: not delay, but a steady output of low-context decisions made quickly, each individually defensible, collectively moving the system somewhere nobody chose.

A nine-hour offset does not slow a team down. It teaches them to stop asking questions.

Three to four hours of genuine overlap is the threshold where a team runs on questions rather than on inference. Below two hours you need a different mechanism: a written decision protocol and somebody on the delivery side with the context and the authority to decide locally and be held to it. Which means that below two hours of overlap you are no longer buying hours. You are buying judgement, and judgement is priced differently.

The specification burden moves onto you

A team with deep context can be given an outcome. A team with thin context needs a specification. Somebody has to write it, and that somebody sits on your side of the boundary — usually the most senior person you have, because they are the only one who knows the answers.

This cost surprises people because it does not feel like a cost. It feels like doing the job properly. But a specification complete enough to be executed without context is most of the design work already done. Deciding what happens when the payment provider returns a soft decline, when the tenant is mid-migration, when two admins edit the same record at once — that is the expensive thinking. Write it down in enough detail to be implemented literally and you have finished it; the implementation is the cheap half. You are not buying engineering at 38 euros an hour. You are buying implementation at 38 euros an hour and paying your own architect's fully loaded cost to do the engineering.

Rework, and the arithmetic of the effective rate

Define rework precisely or the conversation goes nowhere: material change to merged code within ninety days, for a reason other than a genuine requirement change. Ten to fifteen percent is healthy, the normal cost of learning a system. Above thirty percent you are rebuilding continuously and paying for both passes. Almost nobody measures it, and it is a git query and one focused afternoon.

Put coordination and rework together and you get an effective rate, which is the only rate worth comparing. Take a nine-month build under two plausible sets of assumptions:

• Six engineers at 38 euros an hour, 30 percent coordination overhead, 30 percent rework. Productive fraction 0.70, keep fraction 0.70, so 38 / 0.49 is about 78 euros. Add client-side specification and review worth roughly 12 euros per vendor hour: an effective rate near 90.
• Three senior engineers at 95 euros an hour, 15 percent coordination overhead, 12 percent rework. 95 / 0.748 is about 127 euros. Client-side burden is far lighter, perhaps 4 euros per vendor hour: about 131.

Read that honestly: per hour the cheap model still wins, 90 against 131. The effective rate does not defeat the low rate on its own, and anyone claiming otherwise has rigged the assumptions. The comparison flips only on hours required. If the senior team reaches the same working outcome in 40 percent fewer hours — fewer people, fewer handoffs, fewer wrong turns, less scaffolding built to protect against whoever arrives next quarter — then 0.6 times 131 is about 79 per equivalent hour and the order reverses. That 40 percent is the entire argument for seniority. It is not automatic, it is not the birthright of any country, and you should make anyone claiming it show evidence.

Knowledge leaves twice: rotation, then handover

Annual attrition of 20 to 30 percent is normal at large delivery vendors, and project-level rotation runs higher still, because internal reassignment never shows up in an attrition figure. Every replacement costs six to ten weeks to nominal productivity on a non-trivial codebase, and closer to six months for the tacit layer: why the retry backoff has that strange shape, which export file breaks the importer, which module nobody refactors before the audit. That ramp is billed at full rate, and it recurs.

The second-order effect is the expensive one. Codebases adapt to rotation. Teams that expect to be replaced write defensively — extra indirection, configuration where a decision belonged, abstractions covering cases that do not exist — because nobody trusts the next person to understand the direct version. Each choice is individually rational. Collectively they produce an architecture shaped by a staffing policy rather than by a problem, and you pay interest on it for years. You can usually read a vendor's retention rate off their code.

Then the whole team leaves at once, and that is handover. Planned from the start it costs perhaps 3 to 8 percent of build cost; discovered at the end, upward of 20 percent, and it arrives at the worst moment, because handover only becomes urgent once the relationship is already strained. These questions belong in due diligence, not in an exit negotiation:

• Who owns the CI configuration, the infrastructure definitions and the secrets, and where do they live on day one?
• Can an engineer with no vendor contact bring the system up from a clean machine using only the repository? Test that in month two, not month twenty.
• Which named individuals are committed, for how long, with what notice on replacement?
• Are the tests a description of the system's behaviour, or a coverage number produced to satisfy a clause?

Three models, honestly compared

The standard engagement models differ mainly in where they put risk, and the price gaps between them are roughly the market's estimate of that risk. Choosing the wrong model costs more than choosing the wrong country.

Staff augmentation

You buy hours and keep everything else: architecture, sequencing, specification, integration, risk. The rate is lowest, and correctly so, because you are doing more of the work. It fits when you have genuine internal engineering leadership and a backlog of well-understood work to feed it. The failure mode is quiet and common — your senior engineers become full-time ticket authors and reviewers, and you lose your best people's output at roughly three times the hourly rate you saved.

Managed team

You buy a unit with its own lead, its own review culture and its own internal coordination, typically 20 to 40 percent above augmentation rates. That premium is the coordination tax moving onto someone whose job is to absorb it. It suits scope that is real but still evolving, where outcomes can be defined a quarter at a time. The failure mode is metric capture: you agree to velocity targets, the vendor optimises them faithfully, story points climb and the product does not move. Define outcomes in the product's own units — checkout completes under 400ms at p95, the migration finishes with zero manual reconciliation — never in vendor-side units.

Outcome-based

You buy a result and transfer the risk, at a premium that usually runs 25 to 40 percent. Anyone pricing it materially lower either has more context than you think or intends to recover it through change control. The model fits when scope is genuinely knowable and interfaces are stable: a data migration, a systems integration, a replatform with a fixed target, a compliance deliverable with an external definition of done. The failure mode is that change control turns adversarial and the cheapest path to done becomes the one that satisfies acceptance criteria literally. So write acceptance criteria you would be content to have satisfied literally by somebody who dislikes you.

When the low rate is genuinely the right call

Rate arbitrage is real and legitimate. A senior engineer in Bucharest, Krakow or Porto costs materially less than the same engineer in Zurich or the Bay Area, for reasons about housing, currency and local salary bands rather than capability. Anyone treating that gap as evidence of lower quality is selling proximity. The mistake buyers actually make is not purchasing distance — it is purchasing juniority and recording it as savings. Cheap hours are efficient wherever context is already written down:

• Specification-complete, high-volume, low-ambiguity work: porting, localisation, test automation, data migration against a written target schema.
• Long-lived maintenance of a stable system whose behaviour is described by a test suite rather than by the people who built it.
• Parallel work behind a stable interface, where a wrong decision is contained by the interface instead of propagating through the design.
• Anything where you already hold the internal seniority to absorb the specification burden and that seniority is not your bottleneck.

The inverse is equally sharp. Cheap hours are expensive exactly where context lives in people's heads: early product work, anything touching money or regulation, and any system whose requirements are still being discovered rather than transcribed. Most engagements that go badly are the second kind, priced and staffed as though they were the first.

Seniority and context, not geography

Every cost in this article is a cost of missing context. Coordination is the price of distributing it. Latency is the price of retrieving it. Specification is the price of writing it down. Rework is the price of not having it. Rotation is the price of losing it, and handover is the bill for all of it at once. A rate card prices hours; context decides how many hours you need. That is why two teams on identical rates can differ threefold on total cost, and why the geography argument is mostly noise — a low-context team in the next building burns a budget just as efficiently as one nine hours away, and does it while everyone feels reassured.

We work from Bucharest: two hours from London, one from Frankfurt, with real overlap into the US morning. A small senior core, and a network of fifty-plus engineers we bring into projects rather than staff them from. Twenty years and a hundred-plus projects mostly teach you where rework comes from — decisions made quickly by people without enough context to make them, because asking was expensive. So we optimise for the opposite: fewer people, more context, decisions made locally by someone senior enough to own the consequences. It costs more per hour. It is usually the cheaper way to get the thing built.