Hiring an offshore development team without the usual disappointment

We hear the same story often enough to recognise it before it is finished. A company tried an offshore team, it went badly, and now offshore development is treated as a category mistake rather than as one bad supplier.

Having been on the receiving end of that scepticism for nine years, and having taken over several projects left behind by other vendors, we can say that failures cluster. Five mistakes cover most of them, and all five are avoidable before you sign anything.

Mistake one: not knowing who will actually do the work

The most common failure. You meet impressive senior people during the sales process. You sign. Then the work is assigned to whoever is free, sometimes juggling three clients at once.

The fix: insist on interviewing every named engineer before they start, exactly as you would for an in-house hire. Ask whether they will work exclusively on your account. Put both in the contract.

A vendor unwilling to let you interview the team is telling you they cannot predict who the team will be. Believe them.

Mistake two: buying a specification instead of a relationship

Companies burned once often over-correct into a detailed fixed-price contract, believing precision protects them. It rarely does. Software requirements are discovered as they are built, and a rigid contract turns every discovery into an adversarial change request.

The fix: for anything exploratory, use a dedicated team or time-and-materials with a monthly cap. Reserve fixed price for genuinely settled scope — a defined integration, a redesign of an existing system, a migration.

Where you do want fixed price, pay for a discovery phase first. An estimate produced without discovery is a guess with a number attached.

Mistake three: treating time zones as someone else's problem

"They are eight hours behind, so we send requirements at the end of our day and get work the next morning." This works for two weeks. Then a question arises that blocks progress, and the answer takes 24 hours, and it happens again the next day.

The fix: agree a fixed overlap window in writing — the specific hours both sides are available for live conversation. Four hours is enough. From Kochi that means a shared morning with Europe, most of a day with the Gulf and APAC, and a shifted schedule for the US.

Then build the process for asynchronous work in the other hours: written updates before your morning, recorded demos, decisions logged rather than discussed only in calls.

Mistake four: leaving IP and access ambiguous

We have taken over projects where the client had no repository access, no cloud account credentials, no domain control and no signing keys. Everything was in the vendor's accounts. Leaving was not a commercial decision but a technical hostage situation.

The fix, non-negotiable from day one:

• Repositories in your organisation, with the vendor as a collaborator
• Cloud infrastructure in your account, billed to you directly
• Domain and DNS under your control
• App store accounts registered to your company
• IP assignment in the master agreement, plus individual undertakings from each engineer

Any pushback on these is disqualifying. There is no legitimate reason for a vendor to hold them.

Mistake five: no way to see progress except a status report

If your only visibility is a weekly summary written by the vendor, you will find out about a slip when it is too large to hide.

The fix: ask for a working environment you can log into from the first sprint, access to the repository and its commit history, access to the ticket board, and a demo at the end of every sprint. None of this is unusual, and any competent team already works this way.

Watch the shape of the commit history rather than the count. Steady activity across the team is healthy. A vendor who resists giving you access is protecting something.

Questions that reveal how a vendor really works

Beyond the portfolio, these tend to be informative:

"Tell me about a project that went badly and what you did." Everyone has one. A vendor who claims otherwise is either new or not being straight. Listen for whether they take responsibility or blame the client.

"What would make you turn down this project?" A partner with standards has answers. A body shop does not.

"Who fixes a production bug at 11pm, and what does that cost?" Support arrangements are where vague promises live.

"Walk me through your estimate." You want to hear about breakdown, assumptions and risk buffer. "Based on experience" is not an estimate.

"What happens if we want to leave in six months?" A confident partner has a documented handover process. Discomfort here is a signal.

What good actually looks like

From our own client relationships, the ones that work share these traits:

• One named person on the client side who can make decisions
• A fixed weekly rhythm — standup or written update, sprint demo, monthly review
• Direct engineer-to-client communication, not everything filtered through an account manager
• Documented decisions, so nobody relies on memory of a call three months ago
• Honest early escalation when something slips, rather than a recovery attempt in silence

On cost

The rate difference is real and it is the reason most companies look offshore. Senior engineers in India cost roughly a third of equivalent Western in-house cost.

But the cheapest quote is almost always the most expensive outcome. Rates below about USD 2,000 per month for a senior engineer mean either a junior labelled senior, or someone working on several accounts simultaneously.

Judge on total cost of the outcome: what was delivered, what needed rework, what it costs to maintain, and how much of your own management time it consumed. On that measure, the mid-priced competent partner beats the cheap one every time we have seen it tested.