Cheap Hours, Expensive Projects: Pricing US, Nearshore and Offshore Teams Honestly

Comparing engineering teams by hourly rate is like comparing cars by the price of a gallon of fuel: the number is real, and it leaves out how far you get on it. A project's cost is the rate multiplied by the hours, and team location has a much larger effect on the hours than most comparisons admit. No delivery model is best for all work. Each one fits a different kind of work, and you can tell which is which before you sign.

Terms first

The labels are used loosely, so here is how this article uses them for a company based in the United States.

• Onshore: the team works in the US, in or near your time zones.
• Nearshore: the team works in a nearby country with similar working hours. For US companies this usually means Latin America or Canada.
• Offshore: the team works many time zones away, commonly in Eastern Europe, South Asia or Southeast Asia.

A caution before going further: anyone who tells you one of these is always the right answer is describing what they sell. Offshore delivery is the best choice for some work, and this article will say where.

The equation behind the invoice

Write the cost of a piece of work like this:

Total cost = rate x (building hours + rework hours + coordination hours) + the cost of delay

The rate is the only term that appears in a proposal. The rest decide the outcome.

Here is an illustration with invented round numbers, chosen only to show the mechanics. These are not market rates.

Suppose Team A charges 100 per hour and Team B charges 50. The work needs 1,000 hours of building. Team A, working the same hours as your product owner, redoes 10 percent of its output and spends 10 percent on coordination: 1,200 hours, total 120,000. Team B, with two shared hours per day and requirements that are still changing, redoes 40 percent and spends 25 percent on coordination and documentation: 1,650 hours, total 82,500.

Team B is still cheaper on paper. Now add the last term. Team B's version took four months longer because each question cost a day. If the system was meant to remove a manual process or open a sales channel, four months of that benefit is gone, and it never appears on the invoice.

Change the scenario to work with a complete, stable specification. Team B's rework drops to 12 percent and coordination to 12 percent: 1,240 hours, total 62,000, with no meaningful delay. Here the lower rate is a real saving.

The lesson from the arithmetic is that the rate matters most when the other terms are small, and they are small only for certain kinds of work.

What actually moves the hours

Shared working hours

The time difference matters less than the number of hours per day when both sides are at their desks. With two shared hours, a question asked in your afternoon gets its answer the next morning, and a follow-up takes another day.

For stable, well-specified work, questions are rare and this costs almost nothing. When the team is still learning what to build while building it, questions come up hourly. Each one forces a choice between waiting and guessing. Waiting costs calendar time. Guessing is faster, and a share of the guesses will be wrong.

Rework

Rework is output that functions correctly and solves the wrong problem, so it has to be done again. It is the largest hidden cost in distributed delivery and almost nobody tracks it. If a vendor cannot tell you roughly what share of delivered work comes back for changes, they are not measuring it.

The documentation burden

When you cannot ask, you have to write. Some of that is good discipline. Written specifications, recorded decisions and clear acceptance criteria help any team. Beyond a certain point, though, you are running a documentation project next to the software project, and your most senior people spend their days writing instructions instead of making decisions.

Turnover

When an engineer leaves, a replacement needs weeks to become productive, wherever they sit. The damage is greater when knowledge is concentrated in a few people and little of it is written down. Ask about it directly, because average tenure on your kind of engagement varies a great deal between firms, in every region.

Coordination

Every additional location adds scheduled meetings, summaries, handoffs and one more place where a decision can sit waiting. Language and communication style count as well. A team that says "yes" to mean "I heard you" instead of "I agree and it will be done" will cause misunderstandings that surface as rework.

Matching the model to the work

The useful question is not which model is better. It is which model fits the work in front of you.

Most mid-sized companies have work in several of these rows. The expensive mistake is to pick one model for everything, usually on rate, and then find that the discovery work suffered or that simple volume work was overpaid.

When the law or the contract decides for you

For some work, location is a constraint to be checked before any cost comparison.

Health data. Under HIPAA, a vendor that handles protected health information for a covered entity is a business associate, and a subcontractor that handles that information for the vendor is a business associate as well. Each link in the chain needs a written agreement. This means an offshore team with access to production health data is workable only if it is explicit: the entities are named, the agreements are signed, and access is controlled and logged in a way that would hold up in an audit. If a team can read patient records while being absent from every one of those agreements, you have a compliance problem that an auditor will eventually find.

Contractual residency clauses. Many customer contracts, and many government and financial programs, state where data may be stored and from where it may be accessed. Some of them rule out foreign access entirely. Read your own customer contracts before you compare vendors, not after you have chosen one.

A practical workaround. Teams outside the US can often work productively without touching regulated data, using synthetic or de-identified datasets in development and leaving production access to a small onshore group. This has to be designed in from the start.

This section is general information, not legal advice. Have counsel confirm what applies to your data and contracts.

The arrangement that fails most often

The worst results I have seen do not come from offshore delivery as such. They come from a split: architecture is decided by one group in one country, the code is written by another group somewhere else, and neither group owns the result in production.

The architects are not present when their decisions meet reality. The developers implement designs they did not choose and cannot easily question. When the system fails at night, the people who understand why it was built that way are asleep, and the people who are awake do not have the authority to change it.

The fix is a rule about ownership more than about geography: the people who make the architectural decisions should also be the people who get paged when those decisions go wrong. A blended team works well when it is one team with shared ownership, shared channels and a shared rotation.

Six questions that make vendors comparable

Put the same questions to every candidate, whatever their location. Precise answers tell you more than the rate card.

1. Which hours of the day will your team and ours both be working? Ask for clock times in your time zone. "We are flexible" is not an answer.
2. When a developer has a question about a requirement, who answers it and how quickly? The reply should identify the person responsible and commit to a turnaround you can believe.
3. How long do engineers typically stay on an engagement like this one? If the answer is vague, treat that as the answer.
4. Who makes the architecture decisions, and do they write code on this project? If the designers and the builders are different groups, budget for the translation between them.
5. Production fails at 2 a.m. our time. Who is called, and are they awake? This tells you whether support is a real capability or a contract clause.
6. Who will be able to access our production data, from which countries, under which agreements? For regulated work this is the first question, not the last.

Specific answers to all six can only come from a vendor with real practice in this way of working. Give that more weight than a moderate difference in rate.

A quick way to run your own comparison

For each proposal, write down four numbers next to the rate: shared hours per day, the expected rework share for this type of work, the weekly hours your own staff will spend on coordination and documentation, and the months to first usable release. Then recompute the total with those included. The ranking often changes.

Location also does nothing to the underlying size of the project. That is set by the systems to integrate, the data to migrate and the compliance regime in scope, and it applies to every team equally.

Which parts of your work need to sit close to you?

Tell Trivo what you are trying to staff. We will say plainly which parts need same-day answers from a team in your time zone and which can sit elsewhere, even if the honest conclusion is that another model fits better than ours.