Onshore, nearshore or offshore: choosing where the work happens

Almost every article about onshore, nearshore and offshore delivery is organized as a cost ladder, with a table of countries and an hourly rate beside each one. That framing is popular because it is easy to write and easy to skim, and it is close to useless for the person actually making the decision, because it answers a question that is not the hard part. The hourly rate is the most visible variable and one of the least predictive.

The harder question, and the one that separates arrangements that work from arrangements that quietly fail, is what management model sits underneath the geography. Two companies can hire engineers in the same city, at the same rate, through the same partner, and have completely different experiences, because one bought a defined scope and the other built a standing team that it directs. Those are different products with different failure modes, and the country they happen in is a secondary detail.

This article separates the two decisions the search results keep collapsing. First, what the location choice actually trades, with the overlap hours computed rather than asserted. Second, the four control models and what each one demands of you. Then how the two interact, what the rate does not include, how each arrangement fails, and the questions worth asking before signing. We run a delivery center in Hanoi and we also do project work and augmentation, so the trade-offs here are the ones we watch play out, and our offshore development services page describes how we structure the version we run.

You are making two decisions, and only one of them is about geography

The search results treat this as a single question with three answers. It is two questions with a handful of answers each, and they are close to independent. The first is where the engineers physically are, which sets the time zone offset, the legal jurisdiction and roughly the labor market rate. The second is who employs and directs them, which sets how requirements reach the team, who is accountable when something is wrong, and what happens when the plan changes. Location is the visible decision. Control is the one that decides how the arrangement feels to work in.

The clearest evidence that these get collapsed is that people search for the difference between outsourcing and offshoring as though the two words were competing options. They are not alternatives, they are answers to different questions. Outsourcing means somebody outside your company employs the people. Offshoring means the work happens in another country. You can outsource to a vendor two miles away, and you can offshore by opening your own subsidiary and hiring your own employees in another country. Large companies do both of those routinely.

Getting the order wrong is what produces the familiar bad outcome. A company decides to reduce cost, picks a country from a rate comparison, engages the first credible vendor there, and only then discovers what it actually bought: a fixed scope contract when the requirements were still moving, or a standing team when nobody internally had the capacity to direct one. The country was never the problem. The unexamined control model was.

So take them in the order that makes the second decision easier. Decide the control model against two things you already know: how stable your requirements are, and how much engineering leadership you have to spare. Then decide the location against one thing, which is how much of the work needs real-time conversation rather than written handover. Doing it in that order narrows the field quickly, and it means the rate comparison arrives at the end, when you finally have enough context for a rate to mean something.

The two axes, and the words that belong to each

The word	Which question it answers	What it does not tell you
Onshore, nearshore, offshore	Where: the time zone and jurisdiction	Nothing about who manages the team or who employs them
Offshoring	Where: work moved to another country	Nothing about whether the people are your employees or a vendor's
Outsourcing	Who: somebody outside your company employs them	Nothing about which country they are in, or even whether it differs from yours
Staff augmentation	Who: contracted engineers inside your own team and process	Nothing about location, and nothing about who carries delivery risk
Offshore development center	Both, partly: a standing team you direct, employed abroad by a partner	Nothing about whether your requirements are stable enough to justify it

The vocabulary is the source of most of the confusion. Each of these words answers one of the two questions, and none of them answers both.

What onshore, nearshore and offshore actually trade

The three location models sit on a single spectrum, and the thing that varies along it is not really cost. It is the number of hours per day in which a question can be asked and answered without waiting. Cost correlates with that, which is why the cost ladder framing is not exactly wrong, but the overlap is the mechanism and the cost is a side effect. Treating cost as the variable leads to comparing the wrong things.

Onshore means the same country as you. Full working day overlap, the same holidays, the same legal system, the same employment norms, and the highest rate of the three by a wide margin. Nearshore means a nearby country, usually within one to three hours. Most of the working day overlaps, the saving is real but moderate, and cultural and legal differences exist but are usually manageable. Offshore means a distant time zone, typically six hours or more. The saving is the largest available, and the overlap is a window rather than a day. What the offshore end of that spectrum looks like in one real market, including the objections buyers raise about it and the answers that hold up, is covered in our buyer guide to software outsourcing in Vietnam.

Those overlap figures are arithmetic and worth doing rather than accepting. Two ordinary working days of nine hours each, at an offset of N hours, share nine minus N hours, and at nine hours or more they share nothing at all. Hanoi against London is seven hours in January, so two shared hours, and they fall in the London morning because that is the end of the Hanoi day. Hanoi against United States Pacific time is fifteen hours, so the two ordinary days do not intersect: overlap there is not small, it is zero, and it exists only because somebody deliberately moves their day.

Which is the second thing worth being clear about. A shifted day is a legitimate and widely used option, and it is how most successful arrangements across large offsets actually work. But it is not free, and the cost is not shared: it is paid entirely by whichever team shifts, in early mornings or late evenings, indefinitely. That is a sustainable arrangement when it is explicit, scheduled, compensated and staffed by people who agreed to it. It degrades quickly when it is assumed, because the people paying it did not choose it and the enthusiasm runs out before the project does.

How to ask about overlap

Do this

• Ask for named hoursWhich hours, in my time zone, will your team reliably be available for live conversation, on ordinary days, without anyone working outside their contracted hours?
• Ask who is shiftingIf the window requires someone to work outside normal local hours, ask which side, how it is compensated, and how long people have sustained it.
• Ask about the escalation pathOutside the window, what is the guaranteed response time for something urgent, and what qualifies as urgent?
• Put the answer in writingA committed window in the contract is worth more than a generous one in a sales conversation, because only one of them survives a change of account manager.

Not this

• Accepting adjectives"Significant overlap" and "flexible hours" are not numbers. They cannot be planned around and cannot be held to.
• Assuming goodwill scalesIndividuals will absolutely take a 22:00 call to be helpful. A team will not do it every week for two years, and planning as though it will is planning to be disappointed.
• Averaging across the yearDaylight saving moves the offset by an hour, and the two sides rarely change on the same date. Ask about the narrow half of the year, not the average.
• Ignoring the calendarPublic holidays differ, and so does the position of the main annual holiday. A window that exists 250 days a year still has weeks where it does not.

Overlap is the one variable in this decision that can be pinned down precisely before signing anything, which makes it the easiest place to tell a specific vendor from a vague one.

The four control models, and what each one demands of you

The second decision has four common answers. They are usually described in terms of what you get, which makes them sound like a menu of increasing convenience. It is more useful to describe them in terms of what they require from you, because that is what determines whether the arrangement works, and it is the part vendors have the least incentive to emphasize.

Hiring in-house means you employ the engineers. You carry recruitment, which is slow, and retention, which is permanent, and you get the maximum possible control and continuity in return. It is the right answer when the capability is core, the roadmap is long, and you can genuinely compete for the people in your local market. The honest constraint is lead time: filling a senior role can take months, and a plan that depends on hiring three of them by a quarter boundary is not a plan.

Staff augmentation means contracted engineers work inside your team, your process and your management. It is fast, it flexes both ways, and it fits a known capability gap on a defined horizon. What it requires is that you already have functioning engineering management, because augmentation adds hands and adds nothing else. Given to a team with no technical lead, it reliably produces a group of capable people waiting for direction that never quite arrives.

Outsourcing a project means you hand over a defined scope and receive a result. The vendor decides how to build it and carries delivery risk against the specification. That trade is excellent when the scope genuinely is fixed and specified well enough to be contracted against. It is poor for exploratory product work, because every discovery becomes a change order, and the change order conversation eventually becomes the relationship.

A dedicated center, often called an offshore development center, is a standing team that a partner employs and you direct. You set the backlog, the standards and the architecture; the partner handles employment, office, payroll and local compliance. It suits a long product roadmap where requirements will keep moving, and it requires real engineering leadership on your side, because you are managing a team rather than buying an outcome. It is the model we run in Hanoi, and it is the one that most often gets bought by companies that actually wanted one of the other three. If that is the model your answers point at, our offshore development center guide covers setting one up, staffing it and the ways it goes wrong in far more detail than this comparison can.

What each control model asks of you

	Requirements stable?	Needs your eng. leadership	Speed to start	Flexes down easily
In-house hiringMaximum control, slowest start	either	Yes	No	No
Staff augmentationHands, not direction	either	Yes	Yes	Yes
Outsourced projectAn outcome, against a spec	Yes	No	partly	partly
Dedicated centerA team you direct	No	Yes	partly	partly

Read down the column that matches what you have, not across the row that matches what you want. The mismatch between those two is where most disappointment in this decision comes from.

How the two decisions interact

Once both axes are on the table, the interaction is straightforward and mostly one-directional: the control model changes how much the location matters. Some models are highly sensitive to overlap, and some barely notice it.

Staff augmentation is the most sensitive. Contracted engineers sitting inside your process attend your standups, your reviews and your planning, so a two hour window means those ceremonies all compete for the same two hours, and anything unresolved waits a full day. Augmentation across a large offset can work, but it works by being run deliberately as an asynchronous arrangement, which is a different operating model from the one most teams imagine when they buy it.

Outsourced project work is the least sensitive, for the same reason it is risky elsewhere: the interface is a specification and a deliverable rather than a daily conversation. If the scope really is fixed, a large offset costs you little, and this is why offshore project outsourcing has a long history of working for well specified, self-contained work.

A dedicated center sits in between, and where exactly depends on how you run it. If the team has its own lead, its own product context and authority to make decisions inside agreed standards, the overlap window is used for alignment rather than instruction and two or three hours is genuinely enough. If every decision routes through you, the window becomes a bottleneck and the arrangement inherits the sensitivity of augmentation without the flexibility.

In-house hiring in another country is the outlier, because it removes the vendor and keeps the geography. You get full control and you also get the full burden: a legal entity, payroll, local employment law, and a recruitment problem in a market you do not know. That is a reasonable trade at sufficient scale and a poor one below it, which is the specific gap a dedicated center exists to fill.

The order that makes this decision tractable

1. 1

   Decide how stable the requirements areStep 1

   Not how stable you would like them to be. If you cannot write a specification you would be willing to be held to, they are not stable, and a fixed scope contract will fight you.

2. 2

   Count the engineering leadership you actually haveStep 2

   Named people with capacity to direct work, not people who could in principle. This is what separates the models that supply direction from the models that consume it.

3. 3

   Pick the control model those two answers implyStep 3

   The combination usually points at one model clearly, and at that point the shortlist of vendors and countries is much shorter than it looked.

4. 4

   Now choose location against the overlap the model needsStep 4

   And only now compare rates, because a rate finally means something once you know what you are buying with it.

Four steps, in this order. Each one narrows the field for the next, which is why doing them out of order feels harder than it needs to.

What an hourly rate does not include

The hourly rate is the number every comparison leads with, and it is a genuinely poor proxy for what an arrangement costs, because several of the largest lines never appear in it. This is not an argument that offshore delivery is secretly expensive. It is an argument that the rate is the wrong thing to optimize, and that optimizing it aggressively is how buyers end up worse off than if they had paid more.

The first hidden line is your own management time. Every model consumes some, and they differ by a lot: augmentation across a large offset consumes the most, a well run dedicated team with its own lead consumes much less, and a fixed scope project consumes little until something goes wrong, at which point it consumes a great deal at once. Management time is real money and it is usually the time of your most expensive and least replaceable people.

The second is rework caused by misunderstanding, which is the cost that scales with poor overlap rather than with distance. A misread requirement caught in a conversation costs minutes. The same misread requirement caught at review, two weeks later, costs the work plus the rework plus the trust. Overlap hours are worth what they cost precisely because they shorten that feedback loop.

The third is lead time, which almost never appears in a comparison and often dominates it. If in-house hiring takes four months and an augmented engineer starts in three weeks, the difference is not a cost saving, it is three months of a product not existing. Depending on what you are building, that can be the largest number in the whole calculation, and it is the one nobody puts in a table.

None of that argues for ignoring the rate. It argues for putting it beside the other lines rather than at the top of the page, and our guide to software development cost works through the same total against a real scope rather than against a rate card.

The fourth is turnover, and it is the one to ask hardest about. Replacing an engineer who understands your domain costs the recruitment, the ramp, and a quiet tax on everyone who has to re-explain the context. Ask any vendor what their annual attrition is on long-running client teams, and what happens contractually when someone leaves. A vendor who has thought about that answers with a process. A vendor who has not answers with a reassurance.

Lines to price before comparing rates

• Your management hours per weekAt the real salary of the people who will spend them, over the expected life of the arrangement rather than the first month.
• Recruitment and ramp timeWeeks until a productive contributor, per model. Convert it into product time not existing, which is the honest unit.
• The cost of the overlap windowIf someone shifts their day, that is a real cost to a real person. Price it, and decide deliberately which side pays it.
• Rework allowanceHigher with less overlap and with looser specification. Estimate it explicitly rather than discovering it as a slipped date.
• Turnover and replacementExpected departures over the engagement, and the contractual remedy. Ask for attrition figures on long-running teams specifically.
• Exit and transferWhat it costs to move the work elsewhere: repository access from day one, documentation standards, and a notice period you could actually use.

Price all of these for each option you are seriously considering. The ordering of your shortlist changes more often than people expect once these are on the page.

How each arrangement fails

Every one of these models fails, and each fails in a characteristic way. That is more useful information than a list of benefits, because the benefits are what you get if things go well and the failure mode is what you should be watching for from the first month. None of these models is the one that does not fail.

In-house hiring fails on lead time and on market depth. The roles stay open, the plan slips quietly because nobody wants to say the hiring will not land, and the work waits. In a thin local market for a specific skill it can simply not be solvable at any salary you are willing to pay, which is a conclusion worth reaching early rather than after two quarters.

Staff augmentation fails when it is used as a substitute for engineering leadership. The engineers are capable, the direction is thin, and the output drifts away from what was needed. It also fails on continuity: if the contract is short and the people rotate, domain knowledge never accumulates, and you pay the ramp cost repeatedly for the same understanding.

Project outsourcing fails at the specification boundary. Everything not written down is either omitted or charged for, and both feel like bad faith from the other side of the table. The predictable pattern is a project that meets its written scope and does not meet the actual need, followed by a change order negotiation that costs more than the original difference of opinion would have.

A dedicated center fails on management and on context. The specific failure is a decision made in a room the offshore team was not in, and never written down. The team builds against a stale understanding, the work is rejected at review, and the conclusion drawn is that the team cannot be trusted with anything important. That conclusion is wrong and self-reinforcing, because the response is to give them less context, which makes the next failure worse.

Symptoms worth taking seriously early

Questions taking two days

The overlap window is too narrow for how the work is actually run. Either widen it deliberately or move decisions to written asynchronous form on purpose.

Work rejected at review repeatedly

Context is not reaching the team. Almost always a decision made verbally somewhere the team was not present.

A change order for everything

The contract shape does not match how stable the requirements really are. This one does not improve on its own.

Capable engineers waiting for direction

Augmentation used where leadership was needed. Adding more people makes it worse rather than better.

The same context explained again

Turnover is eroding domain knowledge. Ask for attrition figures and check the contractual replacement terms.

Nobody can name who decides

The control model was never actually chosen. Go back to the first decision, because nothing downstream will resolve this.

Each of these is an early-stage signal of a specific failure mode rather than a general worry. Naming which one you are seeing tells you what to change.

What to ask before signing anything

By this point the shortlist is usually short, and the remaining work is verification. The useful questions are the ones with specific, checkable answers, because the difference between a vendor who has run this arrangement many times and one who has not shows up in specificity rather than in enthusiasm.

The single most informative request is to speak to the engineers who would actually do the work, and to be allowed to choose which ones. A partner who is comfortable with that is a partner whose bench is real. Discomfort here is worth paying close attention to, because the gap between the people in the proposal and the people on the project is one of the most common and least visible substitutions in this market.

The second is a paid pilot on real work. Not a technical assessment and not a proof of concept, but a small piece of genuine production scope, run the way the engagement would actually run. It surfaces in three weeks what a procurement process cannot surface in three months: how they handle an ambiguous requirement, whether the overlap window holds under pressure, and what their definition of done looks like when nobody is watching.

The third is the exit. Ask what happens if you want to stop, and listen for whether the answer is a process or a reassurance. Repository access from day one, documentation you could hand to another team, a notice period you could realistically use, and no dependency on tooling you cannot take with you. A partner who has thought about your exit is a partner who expects to earn the renewal, and the request itself is a reasonable one that a confident vendor does not flinch at.

The questions, grouped by what they verify

The people

Can we interview the actual engineers?

And choose which ones, rather than meeting a selected pair

Are they exclusive to us?

Or shared across clients between sprints, which changes continuity

What is attrition on long teams?

A figure, for engagements over a year, with the replacement process

The working arrangement

Which hours overlap, exactly?

Named hours in our time zone, committed in writing

Who shifts, and how is it paid?

If the window needs it, which side carries the cost

Who decides what, inside the team?

The decisions their lead can make without asking us

The commercial shape

What is explicitly excluded?

The exclusion list is more informative than the total

How does a change get handled?

Process and typical turnaround, not a clause reference

What does leaving involve?

Notice, access, documentation, and any tooling lock-in

Ask all of them, and compare answers on specificity rather than on confidence. A vendor who has done this many times gives numbers and names; one who has not gives adjectives.

The question that tells you most is not about the company, it is about the engineers. Ask to meet the people who will do the work, and ask to pick which ones. Everything else in a proposal is a claim; that one is a test.

Frequently asked questions

If you want this decision worked through against your own requirements before anybody quotes a rate, we are a software development company in Vietnam that will tell you when a nearer team or a different control model is the better answer for what you are building.