Three parties. Two of them wanted to continue.

A client came to us after losing a developer they didn’t want to lose. The developer hadn’t decided to leave. The vendor had decided for them.

They asked if we could step in. We said yes. And we understood immediately why they were asking, because we’d heard versions of this before.

Vendors don’t talk about this openly, but rotating a developer isn’t a mistake. It’s a rational business decision.

If their model is built around placing engineers across multiple clients and cycling them through projects, a developer sitting with one client for two years is not performing at optimal yield. A new placement generates a higher margin. A developer with two years of context on your system is worth more to someone who hasn’t had them yet.

Most staffing vendors operate with a bench, a pool of engineers waiting for placement. The economics require that bench to stay small. Long-term placements reduce churn through the bench, which looks efficient. But they also reduce the vendor’s ability to respond to new opportunities, and new opportunities are where the margins are. A developer who stays in one place for three years is, from the vendor’s perspective, underutilized capacity. The model is working exactly as intended.

There’s a second mechanism that’s less visible. The best developers in a vendor’s pool are also the most expensive, which means the lowest margin. When a vendor lands a new client, they typically put their strongest people in first. It’s how they demonstrate competence and win the relationship. Over time, as the engagement stabilizes, those developers become candidates for rotation to the next new client. The replacement that arrives is often cheaper, which improves the vendor’s margin on your account. For you, it means the person who impressed you in the first three months is rarely the person managing your system two years later.

The conflict of interest is structural, baked into the model from day one. You’re not dealing with a vendor who made a bad decision. You’re dealing with a vendor whose incentives were misaligned with yours from the start.

Contract language won’t resolve this. The model that makes rotation possible is often the same model that makes the arrangement viable. You can negotiate notice periods. You can’t negotiate away the economics.

Rotation is rational when your model rewards it. It becomes irrational only when trust is the thing your business runs on.

For a large vendor with many active placements, one rotation that goes wrong is a number that moves. For a smaller external partner, there’s no such buffer. Every placement is visible. Every rotation is a story that spreads. At that scale, trust is the only real asset.

There’s also a timing problem. The vendor usually knows a developer is being moved before the client does. The decision is made internally, sometimes weeks before anyone says anything. By the time you hear about it, the replacement process is already running. You’re the last to know about a change that directly affects your system. The developer may know before you too, and is already weighing their options.

Before you sign with any vendor, ask what stability looks like from their side. Not whether they promise continuity. What their model actually rewards, and what it costs them to break it.

If new placements generate more margin than long-term ones, rotation will happen. Not as an exception, but as a feature of how the business runs.

You can verify this before signing. Ask for references, not for competence, but for continuity. Find someone who has worked with their team for three or four years and ask: did the same people stay throughout, and was the quality consistent over time? The answers will tell you whether stability is built into how they operate, or whether it’s something they promise when they’re selling. Most vendors will give you references. Fewer will give you ones that go back four years.

That conversation will tell you more than any contract.