When an outsourcing relationship goes sour, the instinct is binary: the vendor is bad, fire them. But vendor relationships exist on a spectrum, and most problems fall in the middle — fixable if you know what’s actually wrong, catastrophic if you misdiagnose.

Switching vendors is expensive. You lose context, you lose time, and you reset the learning curve. So before you start exit planning, figure out whether you have a broken relationship or a strained one.

Strained vs. broken

A strained relationship is one where the structure is wrong but the vendor is capable. The contract incentivizes the wrong things. Communication is mediated through too many layers. Expectations were never properly aligned. The vendor delivers — but not quite what you need, not quite when you need it. This is fixable.

A broken relationship is one where the vendor can’t or won’t deliver, regardless of structure. They lie about progress. They staff your project with juniors after selling seniors. They miss deadlines and offer excuses instead of solutions. They have no interest in changing the model because the current model makes them money. This is not fixable.

The six signals

Score these yourself, or use our vendor health check for a structured assessment:

Communication quality. Do you talk to the people doing the work, or only to project managers? Can you get a straight answer about project status without scheduling a meeting? Poor communication is usually structural — fixable by changing the communication model.

Delivery accuracy. When something ships, does it match what you asked for? If the vendor builds the wrong thing consistently, either your requirements are unclear or they’re not reading them. The first is your problem. The second is theirs.

Team stability. Are the same people working on your project this month as last month? Constant rotation means the vendor is treating your project as a training ground or spreading too thin. Every new developer costs you two weeks of ramp-up.

Contract clarity. Are deliverables, timelines, and responsibilities clearly defined? Vague contracts produce vague results. If “build the feature” is the level of specification, don’t be surprised when the interpretation differs.

Escalation responsiveness. When you raise an issue, what happens? A strained relationship responds slowly. A broken relationship doesn’t respond at all, or responds with defensiveness.

Value for money. Is the output proportional to what you’re paying? This is the bottom line. Factor in rework — if you pay for 100 hours and spend 30 hours fixing what was delivered, the effective cost is 130 hours.

What to do if it’s strained

Restructure communication. Cut out the middlemen. Your product person should talk directly to the vendor’s developers, not through two layers of project management. Daily or every-other-day standups, not weekly status reports.

Redefine done. Write acceptance criteria for every piece of work. Not “build feature X” but “build feature X such that [specific conditions are met]. We’ll review against these criteria before accepting.” This eliminates the “but I thought you meant…” conversations.

Change the contract model. Move from time-and-materials to milestone-based payments tied to accepted deliverables. This aligns incentives: the vendor gets paid for results, not for hours.

What to do if it’s broken

Document everything first. Before you terminate, ensure you have: full source code access, documentation of what was built, access to all environments and credentials, and a clear understanding of what’s deployed and working.

Plan the handover. The worst way to end a vendor relationship is to cut it off and hope the next team can figure out the code. Overlap the outgoing and incoming teams. Budget two to four weeks for knowledge transfer.

Learn from it. What would you do differently next time? The answer is almost always: clearer requirements, direct access to developers, and milestone-based payments. These three changes prevent most vendor problems.