How to Know When It Is Time to Change Your Mobile Development Vendor

Most underperforming vendor relationships last longer than they should. The reason is not that the problems are invisible. It is that the response to problems — the performance conversation, the 30-day improvement plan, the "let's give them another quarter" — is always available as an alternative to making the harder call.

The performance conversation is the right first move. Sometimes it works. When it does not, recognising that early is what separates a six-month delay from an eighteen-month one.

Why this decision gets delayed

Switching vendors has a real cost: the transition takes four to eight weeks, new vendor onboarding takes another two to four, and there is always uncertainty about what the incoming team will find. Against that cost, the decision to stay feels like the lower-risk option — especially when the current vendor is responsive to feedback and committed to improvement.

The problem is that commitment to improvement and actual improvement are not the same thing. A vendor that responds well to feedback and continues to underperform for six months is demonstrating, through repeated evidence, that the delivery process cannot sustain the standard required. The commitment is genuine. The capability is not there.

The five conditions below are the ones that move the decision from "should we have another conversation" to "the right move is a switch."

Five conditions that make a switch the right call

1. The same delivery problems have survived two or more improvement conversations without changing.

One performance conversation is a signal. Two with the same outcome is a pattern. By the second conversation about the same problem — missed deadlines, recurring quality issues, communication failures — the vendor has had enough information, time, and motivation to fix it. If the pattern persists, the problem is structural. The vendor does not have the process to fix what you are asking them to fix.

2. A board or compliance deadline is at risk and the vendor cannot give you confidence it will be met.

Some deadlines are movable. A board presentation driven by a regulatory requirement is not. A compliance certification with a fixed audit date is not. When a delivery failure intersects with a hard external deadline, the question changes from "are we underperforming" to "can this vendor get us to the date we need." If the honest answer is no, the switch needs to happen with enough lead time for a new vendor to recover the timeline.

3. You have lost confidence in the vendor's self-assessment.

This is subtler than the first two conditions but equally important. A vendor that honestly tells you when things are hard and what the realistic path looks like is a vendor you can work with, even through a difficult period. A vendor that consistently describes the situation as better than it is — that tells you a feature is "almost done" for three weeks, or that the upcoming release is "on track" when your own observation says otherwise — has broken the information loop. You cannot plan around assessments you cannot trust.

4. The vendor owns assets that belong to your product and is reluctant to transfer them.

App Store developer accounts, CI/CD pipelines, monitoring dashboards, proprietary tooling built on your time. If these live in the vendor's infrastructure and the vendor is not transferring them to you on request, you have a dependency that will become a negotiation at the worst possible time. The unwillingness to transfer is itself a reason to accelerate the switch.

5. The performance gap has a measurable cost that is growing.

Every month of delayed roadmap has a cost — in delayed revenue, in lost competitive position, in the compounding backlog that accrues when delivery is slower than your business needs. When that cost becomes material and is continuing to grow, staying with the current vendor is no longer the low-risk option. The risk has moved to the other side.

Three conditions that do not make it the right call

A single bad release. Every vendor has a bad release cycle at some point. A production issue that required a hotfix, a release that was delayed by an unexpected App Store review, a bug that got through QA on a complex feature. One incident is data. A pattern is a problem. Do not make a switch decision on a single data point.

Slow delivery during a complex integration period. When a mobile app is being integrated with a new backend system, a compliance platform, or a major third-party API, delivery slows. This is normal and expected. The question is whether the vendor is transparent about why delivery is slower, what the realistic path back to normal cadence looks like, and whether quality is being maintained even if speed is temporarily reduced. Slowness with honesty and a clear path is different from structural underperformance.

A team that is honest about problems it is actively fixing. A vendor that surfaces problems early, describes them accurately, and delivers on the fix is a vendor worth keeping — even if the problem itself was their mistake. Honesty about failure is rare and valuable. The vendors that cause the most damage are not the ones who make mistakes. They are the ones who obscure them.

The cost of waiting

The cases that come to Wednesday most often are not "we switched too early." They are "we waited six months longer than we should have."

In a typical case, the pattern becomes clear by month four: two missed deadlines, one improvement conversation, one more missed deadline, a second conversation. The organisation gives the vendor a third chance because switching feels disruptive. By month ten, the roadmap is six months behind, a board deadline has been missed, and the switch happens anyway — now with six additional months of compounded delay and a new vendor inheriting a codebase that has accumulated technical shortcuts under delivery pressure.

The transition cost is the same whether you make the switch at month four or month ten. The difference is six months of compounded consequences.

What the transition looks like

A well-run vendor transition has four phases.

Assessment (weeks one and two). The incoming vendor reviews the codebase, the existing documentation, and the delivery history. They identify what is in good shape, what needs attention, and what is a risk. This assessment is not a judgment — it is calibration. A new vendor that cannot give you an honest assessment of what they are inheriting is not ready to take it over.

Parallel operation (weeks three and four). The incoming vendor runs alongside the outgoing one, asking questions, understanding the processes, and confirming the assessment. The outgoing vendor's cooperation here varies. Some vendors run a professional handover. Others are less cooperative. Your contract should specify what handover cooperation looks like. If it does not, add it before you need it.

Ownership transfer (week five). The incoming vendor takes over delivery. The outgoing vendor remains available for questions for a defined period — typically 30 days. New feature delivery resumes. The gap between the last release under the old vendor and the first under the new one is typically two to four weeks.

Stabilisation (weeks six through twelve). The new vendor addresses the issues identified in the assessment, establishes the delivery cadence, and builds the context required to deliver predictably. By the end of this period, delivery should be at or above the standard described in the benchmarks article linked below.

The transition is not zero-cost. It is a known, bounded cost — four to eight weeks — against an ongoing, compounding cost that grows every month the wrong vendor is in place.