Your Development Vendor Is Underperforming: 6 Signs and the Structured Exit Plan

In 13 years running business development at Acquaint Softtech, a software development partner for companies across the US, UK, and Australia, I have been on the incoming side of hundreds of vendor switch conversations. The story is almost always the same. The CTO knew something was wrong 6 to 8 weeks before they acted. They waited because they had invested 3 to 4 months already. They waited because they were not sure if the next vendor would be better. They waited because they did not know what the exit looked like.

---

The wait is the expensive part. Every week you stay in a failing engagement is a week of budget spent on delivery that will need to be rebuilt or is arriving late. The structure of the exit is rarely as disruptive as the anticipation of it. Most structured vendor switches, done correctly, cost 2 to 3 weeks of transition overhead. Three to four months of a failing engagement costs significantly more.

This article covers the 6 signals that confirm a vendor is underperforming rather than just having a difficult sprint, and the structured exit process that cuts the transition timeline. The full handover process is covered in the vendor switching guide. This article focuses on recognising the problem before the switch, not just after the decision is made.

Section 1: The 6 Signs Your Vendor Is Underperforming

These are the signals that distinguish a vendor in a genuine delivery problem from one having a temporary difficult sprint. The difference matters because one responds to process adjustment and the other does not.

Sign 1: Sprint delivery has been below 70% for 3 consecutive sprints

A single sprint below 70% is information. Three in a row is the vendor's actual delivery rate, not a bad month. Delivery rates do not recover without a structural change. If the rate has been below 70% for 3 sprints, the structural change required is either a new process or a new vendor.

Sign 2: The same explanations appear across multiple retrospectives

Unclear requirements, unexpected complexity, resource constraints. Each of these is a legitimate explanation once. When the same category of explanation appears across three or more retrospectives, it is the vendor's operating pattern, not a contextual problem. Patterns require structural solutions, not the same conversation again.

Sign 3: Communication has shifted from proactive to reactive

A vendor delivering confidently sends weekly updates before you ask. A vendor managing a difficult engagement responds to your questions. The shift from proactive to reactive communication is one of the most reliable early signals of a vendor in trouble. It typically precedes missed delivery by 2 to 4 weeks.

Sign 4: Code review is surfacing the same category of issues repeatedly

Not new issues in new areas. The same types of issues in the same areas. Missing error handling, inadequate test coverage, inconsistent naming conventions. This pattern indicates the developer is not incorporating review feedback into their process. The technical debt accumulates every sprint.

Sign 5: You have lost visibility into what is actively being built

If you cannot describe the current sprint's in-progress items without asking the developer or project manager, the delivery process has broken down. You should know, at any point, what is being worked on and where it stands against the sprint commitment. Opaque delivery is a signal of a vendor managing information rather than a vendor delivering transparently.

Sign 6: Scope creep explanations arrive after delivery misses, not before

A vendor who encounters scope complexity should flag it when they discover it, not use it to explain a missed deadline. The pattern of 'we ran into X which we hadn't anticipated' appearing after a miss rather than during the sprint is a vendor managing the narrative rather than the delivery. One instance is understandable. A repeated pattern is a process problem.

Before You Act: One Conversation Worth Having If you have seen 2 or 3 of the above signs, have one direct conversation with the vendor before initiating an exit. Ask specifically: what would need to change structurally, not just tactically, to move sprint delivery above 85%? A vendor who can answer this question specifically and implement the change in the next sprint is worth continuing. A vendor who responds with reassurances and no structural change is confirming the pattern. Most vendors cannot answer the question specifically because the structural problem is the vendor's model, not the sprint process. That answer tells you what you need to know.

Section 2: Distinguishing Underperformance From a Difficult Phase

Not every difficult sprint is a vendor problem. These are the circumstances that explain temporary performance dips without indicating structural underperformance.

A new and genuinely complex integration

If the current sprint involves a third-party integration with poor documentation or unexpected API behaviour, a dip in delivery rate is understandable once. Ask: was this flagged as a risk before the sprint started? If yes, it was anticipated. If not, it is a scope assessment problem.

A developer transition

If the vendor recently placed a new developer, the first 2 to 3 sprints of ramp-up are expected to run below full velocity. This is a structural cost of any developer transition, not a vendor failure. The question is: was the transition managed with proper handover documentation?

External dependency delays

If a sprint's delivery is blocked by a third-party API outage, a client-side decision delay, or an infrastructure issue outside the vendor's control, the delivery miss is contextual. The test is whether the vendor flagged the blocker immediately and proposed an alternative use of the time.

The pattern test is the most reliable diagnostic. One sprint with a valid explanation is information. The same explanation category across three sprints is the operating pattern. The distinction between a vendor having a difficult phase and a vendor structurally underperforming is whether the explanation category repeat across multiple sprints.

For the ongoing measurement framework that helps you identify underperformance patterns before they become crises, the COO guide to managing external dev teams covers the KPIs and red flag framework in detail. Set these up from the start of any new engagement, not after a problem appears.

Section 3: The Structured Exit Plan

When the signals above confirm a pattern rather than a phase, the exit plan is what determines whether the transition costs 2 to 3 weeks or 2 to 3 months. Here is the structured process that produces the shorter outcome.

Step 1: Document the performance pattern

Before any conversation with the outgoing vendor, document: the sprint delivery rate for the last 4 sprints, the specific issues raised in each retrospective, the communication pattern, and the current state of the codebase as you understand it. This documentation serves two purposes: it gives you the data for the exit conversation and it gives the incoming vendor context on where the project stands.

Step 2: Audit your contract for handover obligations

Review the contract for: repository ownership terms, handover documentation requirements, termination notice period, and whether final payment can be withheld pending handover completion. If your contract does not include handover obligations, you are negotiating rather than enforcing, but most vendors will cooperate when the alternative is a public dispute.

Step 3: Select the incoming vendor before notifying the outgoing one

Identify and qualify your replacement vendor before you give notice. The incoming vendor should be ready to start within 2 to 4 weeks of your notice date. Giving notice without a qualified replacement creates a gap that the underperforming vendor may use as leverage to extend the engagement.

Step 4: Give notice and request the handover package simultaneously

When you give notice, simultaneously request the handover package: codebase documentation, environment credentials, third-party service access, and a 2-hour knowledge transfer session with the incoming vendor's technical lead. Combining the notice and the handover request removes any ambiguity about what is expected before the final payment.

Step 5: Structure the first sprint of the new engagement for transition

Do not expect the incoming vendor to hit full velocity in sprint 1. Budget for 50 to 60% of normal velocity in the first sprint. The reduced scope gives the new developer time to review the handover documentation, run the test suite, understand the codebase architecture, and set up their deployment access without racing through the onboarding.

If you need a dedicated development team as the replacement structure rather than individual augmentation, the first sprint scoping is the same but the vendor also takes on the quality management layer that the outgoing vendor failed to provide.

For the incoming vendor side of the transition process, the detailed week-by-week handover structure is covered in the vendor switching guide referenced in the introduction. For the evaluation of the replacement vendor before you bring them in, use the offshore due diligence checklist to verify the incoming vendor's credentials before committing.

Section 4: What to Do Differently With the Next Vendor

The exit from a failing engagement is expensive. Making the same mistake twice is more expensive. These are the contract terms and selection criteria that prevent the same outcome with the replacement vendor.

Sprint delivery rate tracking from Day 1

Set a defined performance threshold in the engagement agreement. Typically 80 to 85% sprint delivery rate over any rolling 4-sprint period. Below this threshold triggers a structured performance conversation rather than a surprise exit.

Named developer in the contract

The developer who starts is the developer named in the contract. Substitution requires client approval and a documented knowledge transfer. Vendor-managed substitution without notice is a contract breach.

Handover obligations at the start

The termination clause specifies the handover package and the knowledge transfer session before the engagement begins. You are not negotiating these at the point of crisis. They are already in the contract.

Communication frequency defined

Weekly written updates, bi-weekly video check-ins, direct developer access via Slack or Teams. Defined in the contract rather than assumed from the relationship.

For the full vendor evaluation process before the replacement engagement starts, the guide to choosing a software development company covers the 8 questions that reveal what is behind a vendor proposal. And the in-house vs staff augmentation comparison is worth revisiting if the failure of the current engagement has raised questions about whether the outsourced model is right for your situation.

Frequently Asked Questions