The signals that most reliably predict a bad offshore engagement are: a quote given without questions, no named technical lead, no access to your own repository, unwillingness to say what the software will not do, and a sales team you never speak to again after signing. Each is visible before you commit.
A meaningful share of our work is taking over projects that went wrong elsewhere. These are the patterns we see most.
A quote before the questions
A supplier who quotes confidently without asking about your integrations, your compliance obligations, your data or who maintains the result is guessing. It may still be a low guess — that is worse, because the gap surfaces as change requests once you are committed and have no leverage.
What good looks like: questions that are uncomfortable. What happens when this workflow fails? Who decides when we disagree? What does the data actually look like?
No named technical lead
If you cannot name the person accountable for architecture, you are buying capacity, not engineering. Ask who makes the expensive-to-reverse decisions and how those decisions get recorded.
What good looks like: a named person, in your meetings, who will tell you when you are wrong.
You do not own the repository
Code written for you should live in your version control from the first commit, in your cloud accounts wherever possible. If a supplier holds it and hands it over at the end, you are exposed for the whole engagement and you will not discover the state of it until the worst possible moment.
What good looks like: your repositories, your accounts, your access, from day one.
Nobody will say what it will not do
Scope defined only by inclusions is not scope. The arguments that damage projects are almost always about something both sides assumed and neither wrote down.
What good looks like: a scope document with an explicit exclusions list.
The team you met is not the team you get
Common enough to be a category. You are sold by senior people and delivered by whoever is available. Ask to meet the engineers who will actually do the work, and ask what happens if one leaves.
What good looks like: you meet them before signing, and replacement is a named process rather than a surprise.
No tests, no pipeline, no monitoring
Ask directly: what is the test coverage, how does a change reach production, what alerts when it breaks, when was a restore last tested? Vague answers here predict the specific failure of software that works in a demo and cannot be safely changed afterwards.
What good looks like: concrete answers, and a willingness to show you.
Everything is possible
A supplier who never pushes back is either not listening or not experienced. Some requests are bad ideas, some problems do not need software, and some should be solved by fixing a process instead. A partner who cannot say so will build whatever you ask and invoice for it.
What good looks like: being told no, with a reason, at least once during scoping.
Timezone treated as a non-issue
Distributed delivery works, but only when someone has designed for it. If nobody can describe the overlap hours, the handover, or when you get answers, it has not been thought about.
What good looks like: a specific answer about overlap, and a working week that matches yours — including the Sunday-to-Thursday week if you are in the Gulf.
The single best test
Ask a supplier to describe a project that went badly and what they changed afterwards. Everyone has one. A firm that cannot produce the story is either inexperienced or not being straight with you, and both are reasons to keep looking.
- offshore
- hiring
- due-diligence
- procurement