Almost every development partner you talk to has a global team. Some say so on the first call. Others say "our engineers" and let you assume Palo Alto, and you find out during the security review, or worse, when a support ticket gets answered at 3am by someone whose name never appeared in the proposal.
The offshore-versus-onshore debate is mostly over, and it ended for an unromantic reason: senior engineers at competent agencies outside the US bill roughly $28 to $60 an hour against $130 to $190 for comparable seniority domestically, and buyers noticed. What still varies enormously is whether a given partner has built the controls that make distributed delivery work. That is what you are actually assessing.
We run this model ourselves, so read this as a partisan document written by someone who thinks the model is fine and the sloppy version of it is not.
Start with the question most buyers skip
Where do the people who will touch our data physically sit?
Ask it plainly and early. Not "do you outsource," which invites a defensive non-answer, but the specific version. A good partner answers in one sentence and volunteers the follow-up. A bad one gets vague, and the vagueness is the finding.
Geography by itself is not the risk. Consistent controls everywhere the data travels is the actual issue, which is also how enterprise vendor-risk teams frame it. A partner with engineers in three countries and one access-control regime is safer than a partner with everyone in one office and shared credentials in a spreadsheet.
The reason to ask early rather than during diligence is that the answer determines whether the partner can work on your project at all. If you are in defence or handling controlled technical data, US-persons requirements may rule out a distributed team no matter how good it is. If you are in healthcare or finance, your own compliance obligations flow down to them. Better to know in week one.
The paperwork that decides how this ends
Four documents, and only one of them is the contract everyone argues about.
IP assignment that reaches the actual engineers. Your agreement with the agency is not automatically an agreement with a subcontractor two steps down. Missing assignment language between the partner and the individuals writing code is a known deal-blocker in prime and subcontractor arrangements, and it surfaces at the worst possible time: during your acquisition, when a lawyer asks who owns the repository.
A subprocessor list you can actually read. Ask for names and countries, not a promise. Then ask what happens when they add one.
Security commitments proportionate to your data. ISO 27001 is the usual baseline enterprises expect, with SOC 2 Type II relevant depending on your sector and customers. Note the nuance that trips people up: your partner's certification does not extend to their subcontractors. Each layer needs its own.
Named delivery accountability. One person, in a time zone you can call, whose job is your project. Not an account manager who forwards things.
Overlap hours are a contract term, not a nice-to-have
This is where distributed delivery actually succeeds or fails, and it gets treated as a logistics detail.
Do the arithmetic before you sign. A team in Pakistan or India is roughly 12 to 13 hours off US Pacific time, which means 9am to 1pm in California is late evening for them. That overlap exists only if someone commits to working it. Eastern Europe gives you a morning window against US East Coast. Latin America gives you nearly a full day against both coasts and costs more.
So ask for a number: how many hours per day will our teams be simultaneously working, and which hours are they? Then get it in writing. "We are flexible" means nobody has decided, and in three weeks it will mean your standup drifts to 7am.
The other half of this is writing. Distributed teams that document well outperform co-located teams that do not, and the savings from a lower rate evaporate the moment every question needs a synchronous call to resolve. Look for evidence of the habit: written specs, recorded demos, decisions logged somewhere findable. Ask to see a real one from another client with the details removed. A partner who cannot produce a single written spec is telling you how they work.
Run a paid pilot before the real thing
The standard vetting sequence used by agencies who subcontract to other agencies is worth stealing: review the portfolio, take two or three references, then run a small paid pilot in the $3,000 to $5,000 range before committing anything that matters.
The pilot is the only step that produces information the others cannot. A portfolio shows what they shipped at their best with unknown help. References tell you how it felt to work with them, filtered through relationships. A pilot shows you their actual code, their actual communication, and how they behave when something goes wrong in week one.
Design it to be diagnostic, not easy. Pick something small but real, with an ambiguity in the requirements that a good team will ask about and a mediocre one will guess at. Then watch which happens. Give it a deadline you can afford to have missed, because how a team handles a slip tells you more than a clean delivery does. And read the code yourself, or have someone who will.
A partner who resists a paid pilot is worth a second look. Not because refusing is disqualifying, but because the reasons are informative.
The questions worth asking, in order
- 1.Where do the people touching our data sit, and who employs them?
- 2.How many hours a day will our teams overlap, and which hours?
- 3.Who is my one accountable person, and what time zone are they in?
- 4.Show me a written spec or decision record from another engagement.
- 5.Whose cloud and repositories does the work happen in, ours or yours?
- 6.What is your IP assignment chain down to the individual engineer?
- 7.What happens if the engineer you assign leaves in month two?
Question five is underrated. Work happening inside your own cloud and repositories, with your access controls and your logging, answers most of a security questionnaire before it is asked, and it means offboarding is a permissions change rather than a negotiation.
Question seven catches something the others miss. Every distributed partner loses people. What you want to hear is a specific mechanism (documented context, a second engineer already familiar with the codebase, a replacement window they will commit to) rather than reassurance.
What this means for your team
- Ask the location question in week one, not during the security review. It is cheap to ask and expensive to discover.
- Get overlap hours written into the agreement as a number.
- Insist the work happens in your cloud and your repositories where the project allows it. This one choice removes a surprising amount of risk.
- Spend a few thousand on a pilot before spending six figures on a build. The information is worth far more than it costs.
- Judge the writing, not the pitch. It predicts the next six months better than any deck.
Our own posture, since you would be right to ask: US-led with accountability in California, engineers working in your environment, overlap hours agreed up front, and a replacement inside 30 days if someone is not right for your team. If you want to test that rather than take our word for it, start with something small and see how we handle it. For the broader selection process, our guide to choosing a software development partner covers the parts that apply to any vendor, and the questions to ask before hiring an AI development company goes deeper on technical due diligence.
Sources
- Full Scale: offshore software development rates by country, 2026
- Relay Human Cloud: offshore team compliance for US companies, 2026
- Nearshore Business Solutions: SOC 2 and ISO 27001 requirements for partners
- AgencyPro: white label versus subcontracting, vetting and pilots