Offshore development has a poor reputation in a lot of businesses that have tried it, and the reputation is mostly earned by a specific failure pattern rather than by the model itself. A company posts a project on a freelancing platform, takes a low bid from a supplier they never spoke to, sends no specification worth the name, receives something unusable three months later, and concludes that offshore does not work.
That is a procurement failure that would have produced the same outcome with a local supplier chosen the same way. The difference is that a local failure gets attributed to the supplier and an offshore one gets attributed to the model.
We are an Indian studio, so treat this with the scepticism it deserves. But the questions below are ones we would rather not be asked, which is a reasonable indication they are the right ones. They apply equally to us and to anyone else you are considering.
Why offshore gets blamed for selection failures
The gap between a good offshore supplier and a bad one is far wider than the gap between offshore and local. That single observation explains most of the disappointment in this market, and it has an obvious implication: effort spent on selection returns more than effort spent deciding whether to go offshore at all.
The structural reason offshore attracts worse selection is that the price difference invites a different buying behaviour. A business that would carefully evaluate three local agencies at sixty thousand will happily take a chance on a five thousand quote from someone they have never spoken to, because the downside feels small. It is not small. The wasted time, the sunk internal effort and the delayed project usually cost more than the fee.
The second reason is that distance hides incompetence for longer. A local supplier who is struggling becomes visible quickly because you can see them, meet them, and sense the discomfort. An offshore supplier who is struggling sends the same reassuring weekly update while nothing works, and the discovery happens at the demo.
Both are solvable. The first by treating offshore selection with the same seriousness as local. The second by insisting on working software rather than status reports from week one.
The four kinds of offshore supplier
They present almost identically in marketing and are completely different products.
Questions that actually separate them
None of these require technical knowledge. The quality of the answers separates suppliers faster than any portfolio review.
Ask who specifically will do the work and whether you can speak to them before signing. A studio with staff will introduce them by name. A body shop presenting as a studio will describe a team. An intermediary will change the subject. This one question resolves more than any other.
Ask what they would talk you out of building. A supplier who agrees enthusiastically with your entire wishlist is selling. One who tells you which third is not worth building is consulting, and worth considerably more. Every project we have run that went well contained a conversation where we argued the client out of something.
Ask to see code from a recent project, or a repository, or design source files. A competent supplier shows you without hesitation. Ask what the handover looks like: who owns the code, where it lives, and what you receive at the end. The correct answer is that you own everything and it lives in your accounts.
Ask how many hours of your working day genuinely overlap with theirs, and listen for a number rather than reassurance. A supplier who says the time difference is not an issue is either not thinking about it or not being straight with you.
In practice
The timezone question nobody asks properly
Buyers routinely ask whether the time difference will be a problem and accept a vague reassurance. The useful question is arithmetic: how many hours a day are both sides at a desk, and what working model does that number support?
Five or more hours, which is roughly the UK against India, supports genuinely collaborative working: daily calls at reasonable hours for both sides, live code review, pairing, and a problem raised in the morning being worked on within minutes.
Three hours, which is roughly eastern Australia against India, supports one substantial scheduled call a week plus written handovers. It does not support daily standups at a time that suits both sides, and a supplier who promises them has not done the arithmetic.
One hour or less, which is the Caribbean or the American west coast against India, requires a genuinely asynchronous model: written daily handovers, questions raised with enough context to be answered without a conversation, and decisions recorded in one place. That works, and it requires more discipline from the supplier than a same-timezone engagement does.
The failure mode is not the size of the gap. It is a supplier who has not planned for it and a buyer who assumed it would be handled.
| Overlap | Working model that actually works | Warning sign |
|---|---|---|
| 5+ hours | Daily calls, live review, pairing | None |
| 3-4 hours | Weekly call plus written handovers | Promises of daily standups |
| 1-2 hours | Fully asynchronous, written-first | Any promise of live availability |
| Under 1 hour | Asynchronous with one fixed weekly slot | Claims the gap does not matter |
Data, contracts and the part your lawyer cares about
Wherever personal data is involved, the arrangement has to be governed contractually and the requirement differs by jurisdiction.
From the UK, India has no adequacy decision, so transfers need the International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses, plus a transfer risk assessment. From Australia, Privacy Principle 8 means you remain accountable for what the overseas recipient does with personal information. Both requirements are routine and any competent supplier will sign without negotiation.
The more useful question is whether the transfer needs to happen at all. For a great many builds, the supplier does not need production personal data. Development against anonymised or synthetic datasets, with production access restricted to named individuals under logged conditions where it is genuinely required, removes most of the exposure and is rarely harder to build against. A supplier who proposes this unprompted is telling you something good about how they work.
On the contract generally, the terms that matter are the ones that cause disputes: specific scope with a defined number of revision rounds, staged payment against verifiable milestones, explicit ownership of code and design files on final payment, named client-side dependencies and what happens to the timeline if they slip, and what constitutes a warranty bug versus a billable change.
This is not legal advice and your own adviser should review any arrangement. The point is that these questions have standard answers and a supplier who finds them difficult is telling you something.
How to structure a first engagement
Never make a large build your first piece of work with an offshore supplier. It is a poor risk decision and a competent supplier will say so themselves.
Start with something small, bounded and genuinely useful on its own: a performance audit with the fixes implemented, one integration off the backlog, a single template built to your design, a two-week automation of a manual process. Two to four weeks of work.
What you are evaluating is not whether they can code, which the portfolio already suggests. It is whether they write clearly, whether they raise problems early rather than presenting them at the end, whether work arrives when promised, and whether the code is something your own developers could pick up and extend. None of those are visible before you have worked together, and all of them determine whether a long engagement succeeds.
Insist on working software in a browser from the first week rather than status documents. Status reports are where struggling suppliers hide. A deployed environment you can open yourself is where they cannot.
If the small engagement goes well, the large one starts with both sides knowing what they are dealing with. If it does not, you have spent a limited amount learning something valuable.
The single most useful contract term
A short notice period with a clean handover obligation. Thirty days, with code, credentials and documentation delivered on termination regardless of the reason. It costs a good supplier nothing because they do not expect to trigger it, and it removes almost all of your downside. A supplier who resists it is telling you what the exit would actually look like.
Warning signs worth walking away from
Some signals are strong enough to end the conversation without further investigation.
Refusing to name the people who will do the work, or being evasive about whether they are employees or subcontracted. Claiming offices in a dozen countries when the engineers are in one, which is common enough in this industry to be a reliable filter. Quoting a fixed price for a requirement neither side has defined, which means the number is either padded heavily or about to be revised.
Demanding full payment upfront. Refusing to give you ownership of code or accounts. Any promise of guaranteed timelines on work that has not been specified. And a supplier whose answer to the timezone question is that it will not be an issue.
Finally, and most reliably: a supplier who cannot explain something in plain language. Technical complexity is real, but anyone who genuinely understands a system can explain it to an intelligent non-specialist. Obscurity is usually concealment, and across a distance it is concealment you will not detect until late.
Key takeaways
- The gap between good and bad offshore suppliers is wider than the gap between offshore and local. Selection matters more than the decision itself.
- Ask who specifically will do the work and whether you can speak to them. It resolves more than any other question.
- Treat the timezone as arithmetic, not reassurance: how many hours overlap, and what model does that support?
- For most builds the supplier does not need production personal data at all. A supplier who proposes that unprompted is a good sign.
- Start with two to four weeks of bounded work. Insist on working software from week one, not status reports.
- Walk away from anyone who will not name their engineers, demands full payment upfront, or says the time difference is not an issue.
Frequently asked
Usually yes, substantially, but less than an hourly rate comparison suggests. Offshore engagements need more written specification and more asynchronous clarification, and occasionally something gets built to a misunderstanding and redone. Budget realistically for that and the saving is still large. Ignore it and choose on rate alone, and you get the experience that gives the model its reputation.
Ask to speak to the people who will actually do the work before signing, and ask to see a repository or design source files from a recent project. Check whether the offices they claim are real by looking at whether they list addresses in many countries while all their engineers are in one, which is a common and reliable warning sign. Then ask for a client reference, ideally on a project that had difficulties.
Specific scope with a defined number of revision rounds, staged payment against verifiable milestones, explicit ownership of code and design files on final payment, and a short notice period with a clean handover obligation covering code, credentials and documentation. That last one removes most of your downside and costs a good supplier nothing.
A freelancer can be excellent value for small, well-specified work and carries total continuity risk, since illness or a better offer leaves you with nobody who knows your system. A studio costs more and survives one person leaving. For anything your business will depend on for years, the continuity is usually worth the premium.
Two to four weeks, bounded, and useful on its own. Long enough to see how they write, whether they raise problems early, and what the code looks like. Short enough to abandon cheaply. Any supplier who pushes you straight into a six-month build as a first engagement is not managing your risk, which tells you something about how they will manage the project.