Nearshore, offshore, or US: the cost beyond the hourly rate
Hourly rate is the smallest term in delivery cost. What time zone overlap, rework, and context loss actually cost, and when each model is the right choice.
There is no universally right answer here, and anyone who tells you otherwise is selling their own delivery model. What follows is the framework we would use from either side of the table, and it points at offshore for some kinds of work.
The comparison is almost always run on hourly rate. That is the one number that is easy to obtain and the one that explains the least about what a project ends up costing.
The terms that actually move total cost
Rate is a multiplier on hours. The interesting question is what determines hours.
Time zone overlap. Not the difference, the overlap. Four hours of shared working time means a question asked at 4pm gets answered tomorrow. On work with stable requirements that costs almost nothing. On work where the requirements are being discovered, every unanswered question is either a day of waiting or a guess, and guesses become rework.
Rework rate. The share of delivered work that has to be redone because it solved the wrong problem. This is where distributed delivery actually gets expensive, and it is almost never measured.
Context loss at handoff. How much has to be written down because it cannot be asked. Some of this is healthy: written specs are good. Past a threshold it becomes a documentation project attached to a software project.
Turnover. Rebuilding context in a new engineer costs weeks regardless of geography. It costs more when the knowledge lives in fewer heads and less of it is written down.
Coordination overhead. Every additional site adds meetings, translation, and one more place a decision can stall.
Which model fits which work
The honest version of this comparison is not "which is better". It is that the models suit different work.
| Work type | Best fit | Why |
|---|---|---|
| Well-specified, stable requirements | Offshore | Low question rate makes overlap cheap; rate dominates |
| Large volume of similar work | Offshore or nearshore | Specification cost amortizes across many units |
| Discovery, architecture, decisions | Onshore or high-overlap nearshore | Question rate is high and answers are needed same-day |
| Regulated data with US requirements | Onshore | Data residency and BAA scope are constraints, not preferences |
| Production incident response | Overlapping your business hours | Whoever is awake when it breaks is the only thing that matters |
| Small team, requirements still moving | Onshore or nearshore | Coordination overhead exceeds any rate advantage |
Where compliance removes the choice
For some work the geography is a constraint rather than an optimization.
If protected health information is in scope, everyone who can access it is in the Business Associate chain, including offshore subcontractors. That is workable and routinely done, but it must be explicit: named entities, signed agreements, and access controls that survive audit. An offshore team accessing production data without appearing anywhere in that chain is a finding waiting to happen. What the agreement covers is in what a BAA actually obligates.
Data residency requirements in some contracts remove the option entirely. Read them before running the comparison, not after.
A comparison you can actually run
Ask every vendor, regardless of geography, the same five questions. The answers are more informative than the rate.
- How many hours per day overlap with our team? Specific hours, not "we are flexible".
- Who answers a requirements question, and how fast? A named role and a realistic response time.
- What is your turnover on engagements like ours? Vagueness here is itself the answer.
- Who owns the architecture decisions? If it is not the team writing the code, expect a translation cost.
- What happens at 2am when production breaks? Whose phone rings, and are they awake.
A vendor who answers all five precisely is describing a delivery model they have actually run. That is worth more than a rate difference, and it is closely related to how to evaluate engineering depth.
None of this determines what a system costs to build in the first place. That comes from the integration surface, the data migration, and the compliance regime, which are laid out in how to size the cost of custom software.
We staff each engagement around the overlap the work actually needs, and agree it before anything starts. What that means operationally is in our security practices, and how we scope work is under custom software development.