Your Outsourced Developer Just Quit. What Your Contract Should Have Said About Replacements.

How Often Does an Outsourced Developer Actually Get Replaced?

More often than most buyers plan for, and the numbers are public. The large IT services firms disclose voluntary attrition in their quarterly results, which makes this one of the few areas of outsourcing risk you can quantify rather than guess at.

Recent reported figures cluster in a fairly tight band. Quarterly disclosures from the major Indian IT firms put Infosys at 12.3%, TCS at 13.5%, Wipro at 14.2% and HCL Tech at 12.4% in Q3 FY26, with all four having run one to two points higher earlier in the fiscal year. At the lower end, EPAM's annual report disclosed voluntary attrition of 8.9% for 2024, down from 13.8% in 2022.

Now do the arithmetic that vendors never put in a proposal. These are per-person annual rates, so the probability that a team stays fully intact falls quickly with team size. At a 13% rate, the chance that a specific six-person team loses nobody over twelve months is roughly 43% — meaning about a 57% chance you lose at least one person in year one. Over a two-year engagement it rises to roughly 81%. On a ten-person team, the one-year figure is about 75%.

That calculation is simple compounding on the published rates rather than a cited statistic, but the conclusion is robust to whatever reasonable rate you substitute. Losing team members is not an edge case to be handled by goodwill when it happens. On any engagement lasting more than a year, it is the expected case, and the only real question is whether your contract anticipated it.

Why Does Losing a Vendor Engineer Cost More Than Losing Your Own?

Because you have less warning, less influence, and usually no visibility into the replacement decision — and because the knowledge that leaves was never written down in your systems.

When your own engineer resigns you typically get weeks of notice, a handover you control, an exit interview, and the ability to decide who picks up their work. When a vendor's engineer resigns you often learn about it after the decision is final, sometimes framed as "we're bringing in someone even stronger." The handover happens inside the vendor's organisation, on their timeline, according to their judgement about what matters.

The knowledge asymmetry is the deeper issue. A vendor engineer who has spent eighteen months on your product holds an enormous amount of undocumented context: why a particular integration is structured oddly, which client reported the bug that led to a workaround, what was tried in 2024 and abandoned. That context lives in their head and, when they leave, it leaves your organisation entirely — because they were never in your organisation to begin with. Your own departing engineer at least leaves behind colleagues who were in the room.

This compounds with the point covered elsewhere on this blog about vendor transitions: an outsourcing relationship concentrates institutional knowledge in people you do not employ. Individual attrition is that risk arriving in small, repeated instalments rather than all at once, and because each instance is small it rarely triggers the response that a full vendor change would.

What Does a Replacement Actually Cost You?

Between one and three months of reduced output per replaced engineer on a non-trivial codebase, and in most contracts you pay full rate for all of it.

The cost decomposes into three parts. There is the gap between departure and the replacement starting, which can be zero if the vendor has bench capacity or several weeks if they do not. There is the new engineer's ramp-up, during which they are billed at full rate while producing well below full output. And there is the drag on everyone else — your existing team members, vendor and internal, lose time answering questions instead of shipping, which is a real cost that never appears on any invoice.

The ramp-up component is the one worth negotiating, because the default allocation is indefensible when you state it plainly: the vendor's staffing turnover creates a productivity loss, and the client pays full rate for it. If a replacement takes six weeks to reach full effectiveness on a $9,000-a-month engineer, that is a five-figure cost transferred to you by an event you had no part in causing.

This is why the replacement clause is worth more attention than most buyers give it. You are not going to prevent attrition — no contract does that, and vendors cannot promise it honestly. What you can do is determine who absorbs its cost, and that is a negotiable term rather than a law of nature.

Which Clauses Actually Protect Continuity?

Four, and they are more readily agreed at signing than most buyers expect — because a vendor confident in its retention has little to fear from them.

Named key-person designation. Identify the two or three individuals whose loss would genuinely hurt — usually the tech lead and whoever holds the deepest domain knowledge — and name them in the contract. Do not name the entire team; that is unenforceable in practice and vendors will resist it for good reason. Key-person status should carry obligations: advance notice of any planned change, and consequences if the person is moved for the vendor's convenience.

Client approval rights over replacements. You should interview and approve any replacement, applying the same bar you applied to the original team. Without this, replacement quality is entirely at the vendor's discretion at exactly the moment their incentives favour whoever is available on the bench.

A minimum overlap period. Thirty days of paid overlap between departing and incoming engineer is a reasonable floor for a substantive role, and it is the single highest-value clause in this list. Overlap is what converts a departure from a knowledge loss into a knowledge transfer. It only works if the departing engineer is still engaged during it, which is another argument for making overlap a contractual obligation rather than a request.

Ramp-up at the vendor's cost. Some portion of the replacement's first weeks should be billed at a reduced rate or not at all. Vendors will negotiate here — a common landing point is a defined ramp period at 50% rate, or full rate with a specified number of free hours. The exact structure matters less than establishing the principle that turnover cost is shared rather than transferred.

Attrition or Rotation — Which Should Worry You More?

Rotation, clearly. Attrition is someone choosing to leave their employer; rotation is your vendor choosing to move them off your account. The first is largely outside anyone's control. The second is a decision made by your vendor, in their interest, and it is the one your contract should restrict.

Rotation happens for reasons that have nothing to do with your project. A larger client escalates and needs a strong engineer immediately. An internal reorganisation reshuffles practice areas. A promotion moves someone into a role that does not serve your account. Occasionally, an engineer who was assigned to win your business is moved to win the next one — the pattern where the people in the pitch are not the people who deliver.

The tell is in how it is communicated. Genuine attrition usually comes with an apology and some awkwardness, because the vendor did not want it either. Rotation tends to arrive pre-framed as an upgrade: new person is more senior, better fit for the current phase, an opportunity to bring fresh perspective. When a staffing change is presented as being in your interest without your having asked for it, that is worth a direct question.

So ask it directly, in writing: is this person leaving the company, or moving to another account? Vendors answer this honestly in most cases, and the answer tells you which problem you have. If the answer is rotation and it happens more than once, you are not experiencing bad luck — you are a lower-priority account, and that is a relationship conversation rather than a staffing one.

How Do You Spot a Continuity Problem Before You Sign?

Ask for tenure data rather than attrition rate. Attrition percentages are easy to present favourably; average tenure of the specific engineers proposed for your team is much harder to dress up.

The most useful question in a selection conversation is: for the engineers you are proposing, how long has each been with your company? A team where the proposed engineers average three years is a materially different proposition from one where they average eight months, regardless of what the headline attrition figure says. A vendor that cannot answer, or answers vaguely, has told you something either about their retention or about whether the proposed team is real yet.

Follow with: are these people currently on another project, and when do they roll off? This flushes out a common pattern where a proposal is staffed with strong engineers who are genuinely employed but not genuinely available, with the expectation that the gap will be filled by whoever is free when your start date arrives.

The employment structure underneath matters too, and it is a fair thing to ask about. A vendor whose engineers are direct employees carries the retention cost itself and has a real incentive to keep people; one that assembles teams from freelancers or subcontractors per engagement has considerably less. It is part of why we employ our engineers directly at StepTo rather than contracting them per project — the honest reason is not that it makes us immune to anyone leaving, because nothing does, but that it puts the cost of turnover on us, where the incentive to prevent it actually sits. Ask any vendor how their engineers are engaged, and whether the ones proposed to you are already on staff.

Finally, ask for a reference from a client whose engagement has run longer than two years, and ask that client one specific question: how many people have been replaced, and how was it handled? Long-running references are far more informative than recent ones, because continuity problems take time to appear.

What Can You Do on Your Side?

Reduce the amount of knowledge that exists only in one person's head — which is the same discipline that makes every other outsourcing risk smaller.

Start with the simplest diagnostic: for each person on your outsourced team, ask what would break if they vanished tomorrow, and how long it would take someone else to pick it up. Anyone whose answer is alarming is a concentration risk, and the fix is not to hope they stay but to reduce what only they know.

The mechanisms are unglamorous and well understood. Require architecture decision records for anything non-obvious, so the reasoning survives the reasoner. Rotate code review so at least two people have read every significant area. Insist that runbooks live in your repository rather than in the vendor's wiki, which you will lose access to. Where a subsystem has exactly one person who understands it, deliberately pair someone else into it before you need to.

Resist the instinct to solve this by demanding your vendor never change anyone. That posture converts a manageable operational risk into an adversarial contract position, and it does not work — people leave jobs regardless of what two companies agreed. The durable protection is that any single departure is survivable, not that departures never happen.

When Is Replacing a Developer Actually Fine — or Good?

Frequently. A blanket continuity-at-all-costs posture is its own mistake, and it is worth naming the cases where change is neutral or positive.

When the engineer was not right for the work. If someone is underperforming or mismatched to the current phase, a replacement is a correction, not a loss. Buyers who have negotiated aggressive key-person clauses sometimes find they have contractually bound themselves to an engineer they would rather swap — which is an own goal. Approval rights over replacements are useful; rigid prohibitions on any change are not.

When the project phase genuinely changed. The team that builds a greenfield MVP is not always the right team to operate and scale it. A vendor proposing different people for a genuinely different phase may be doing exactly what a good partner should. The test is whether the rationale was offered before you noticed, and whether the incoming skills actually match the stated reason.

When the overlap was handled well. A replacement with a real 30-day overlap, a documented handover, and an approved incoming engineer is a manageable event. If your vendor consistently handles departures this way, frequency matters much less. Judge the process, not the count.

When continuity is masking a bus-factor problem you should fix anyway. If losing one engineer would genuinely derail your product, the fragility is the finding. A vendor with zero turnover would simply be concealing it from you for longer. In that sense an early, well-handled replacement is useful information delivered cheaply.

What Should You Do This Quarter?

Four things, whether or not anyone has left recently.

First, read your current agreement's staffing section and establish what it actually obliges the vendor to do when someone leaves. In most mid-market contracts the honest answer is "provide a replacement of comparable skill" and nothing more — no approval right, no overlap, no ramp-up allocation.

Second, list the people on your outsourced team and mark the two or three whose departure would genuinely hurt. That is your key-person list, and it should be in the contract rather than in your head.

Third, ask your vendor for the tenure of each person currently on your account. Do it as routine relationship hygiene, not as a challenge. The answer tells you your real exposure, and the willingness to answer tells you something too.

Fourth, at the next renewal, add the four clauses. A vendor with genuine retention will agree to overlap and approval rights without much resistance, because they expect to comply anyway. Sustained resistance to a 30-day overlap requirement is itself the answer to the question you were asking.