The uncomfortable pattern
Almost every failed offshore project we have been asked to rescue failed for reasons that were visible in the first month and are not specific to offshore. Distance does not cause failure; it removes the informal correction that catches it early.
Drawn from projects that came to us for rescue. The causes cluster tightly, and each has a specific preventive control.
The nine causes, and their controls
1. Scope was never properly written
The client described the product in conversation; the vendor built what they understood. Both parties were acting in good faith and the outputs did not match.
Control: a written scope listing every screen, integration and explicit exclusion, signed before work starts. If it is not written, it will be argued about.
2. No access to code until delivery
The client had nothing until the end, so quality problems and progress misrepresentation were both invisible.
Control: your repository from day one, with daily pushes. This single control resolves more failure modes than any other.
If you implement one thing from this article, make it repository access. It gives you visibility into progress, protects you if the relationship ends, and makes an independent code review possible at any point. Setup takes fifteen minutes.
3. Status reported as percentages
"70% complete" for four consecutive weeks. Percentages are opinions; working software is evidence.
Control: weekly demos of running software. Not screenshots, not a walkthrough of code — something you can click.
4. The vendor lacked the specific capability
A competent team accepted work outside their experience and learned on the project, at the client's expense.
Control: ask what they have not done before. A straight answer indicates honesty; universal confidence indicates a sales posture.
5. Scope grew without the schedule moving
Each addition sounded small. Fifteen of them doubled the work while everyone still expected the original date.
Control: a written change process. Every addition estimated in time and cost, explicitly accepted or deferred to a phase-two list.
6. Too many decision-makers
Contradictory feedback arriving from several stakeholders, days apart, across a timezone gap.
Control: one named decision-maker who consolidates internal input and speaks with a single voice.
7. Payment fully up front
All delivery risk transferred to the client, removing the vendor's incentive to finish.
Control: milestone payments against reviewable deliverables. 30–40% up front is reasonable; 100% is not.
8. Key person dependency
One engineer held all the knowledge and left. Progress stopped.
Control: ask what happens if that person leaves, and require documentation and code review as contractual practice rather than good intentions.
9. Communication decayed silently
Responses slowed from hours to days. Nobody addressed it until the project was badly behind.
Control: an agreed cadence — daily written updates, weekly demos — and treat a missed cadence as a problem in itself, not an inconvenience.
The early warning signals
| Signal | What it usually means | Act by |
|---|---|---|
| Demo postponed twice | Nothing demonstrable exists | Immediately |
| "Almost done" for 3+ weeks | Remaining work was never estimated | Immediately |
| You have not seen the repository | You may not have your own asset | Today |
| Replies slower than during sales | Attention has moved elsewhere | This week |
| Scope discussion replacing progress | Delivery has stalled | Immediately |
| Team members changing quietly | Knowledge loss in progress | This week |
Clients almost always notice these signals and almost always wait. The instinct to give it another two weeks is what turns a recoverable situation into a rescue.
What to do when signals appear
- Get repository access immediately if you do not have it. This is non-negotiable and non-confrontational — frame it as standard practice.
- Request a written list of what is complete versus outstanding, feature by feature.
- Ask for a demo of anything working, however partial.
- Get an independent review of the code if you cannot assess it yourself.
- Stop adding scope entirely until the position is clear.
- Decide from evidence — continue with corrections, replan, or change vendor.
The prevention checklist
Before starting any offshore engagement, confirm all nine are in place:
- Written scope including explicit exclusions.
- Your repository, with daily pushes required.
- Weekly demos of working software scheduled.
- One named decision-maker on your side.
- Written change process agreed.
- Milestone payments tied to deliverables.
- IP assignment in writing.
- Named engineers, with a continuity plan.
- Agreed communication cadence.
Notice that none of these are about geography. Every one applies equally to a vendor in your own city. Offshore does not introduce new failure modes — it removes the informal correction that catches the existing ones early, which is why the formal controls have to be deliberate.
Starting an engagement, or watching one go wrong? Tell us where things stand — we take over inherited projects, and we will be straight about whether the code is worth keeping. See our offshore buyer's guide and rescuing a failed project.