Evaluate an offshore partner on four things: who is technically accountable and whether you can name them, whether code lives in your accounts from day one, how the working day overlaps with yours in practice, and whether they will tell you when you are wrong. Rate, headcount and case study count predict outcomes far less well than any of these.
Rate is the weakest signal available
An hourly rate tells you almost nothing without velocity and quality attached. An engineer at half the rate who needs three times the direction, produces untested code, and leaves you a system nobody can change is not cheaper. The cost surfaces later, as maintenance, as rework, or as the rebuild we get called in for.
Compare on total cost to a working outcome, which means asking about testing, deployment and handover — not on the rate card.
Technical accountability
Ask who makes architectural decisions and how those decisions get recorded. You want a name, in your meetings, who will say "that is expensive to reverse, here is why."
Firms selling capacity rather than engineering cannot answer this, because there is no such person. That arrangement can work if you supply the technical leadership yourself — but know which one you are buying.
Code ownership from day one
Your code should live in your version control and your cloud accounts from the first commit. Not handed over at the end.
This matters for a reason beyond ownership: it makes the state of the work continuously visible. Suppliers who hold code until delivery are not usually being sinister, but you will not discover the test coverage or the shortcuts until the moment you are least able to act on them.
Timezone, designed rather than tolerated
Distributed delivery works. It works when someone has designed for it.
Ask specifically: what are the overlap hours, when do I get answers, what happens to a blocking question raised at four in the afternoon? A supplier who treats the timezone as a non-issue has not thought about it.
If you are in the Gulf, ask whether they work the Sunday-to-Thursday week or expect you to work theirs. The answer tells you how much of their delivery model is genuinely built around clients rather than around themselves.
Willingness to disagree
The most valuable thing an engineering partner does is tell you when you are wrong — that a request is a bad idea, that the problem does not need software, that the deadline and the scope cannot both hold.
A supplier who agrees with everything will build whatever you ask and invoice for it. During scoping, note whether you are ever pushed back on. If you are not, that is data.
What to actually ask for
- The names and profiles of the engineers who will do the work
- A scope document with an explicit exclusions list
- Their answer on test coverage, deployment and monitoring
- A reference from a client whose project went badly at some point
- What happens if an engineer leaves mid-engagement
That fifth question is the one most suppliers have not rehearsed, and the answer is revealing.
On location
Where a team sits matters much less than how it is run. There are excellent firms and poor ones in every market, and the correlation between country and quality is far weaker than procurement processes assume.
What does correlate: whether there is a named technical lead, whether you own the code, whether the working week is designed around yours, and whether anyone will tell you no.
- offshore
- procurement
- due-diligence
- delivery