I’ve been on both sides of this one.
As a government ICT division manager in the Philippines, I’ve sat through the sales calls. Two or three sharp, articulate senior developers walk you through their process. They ask smart questions. They’ve clearly done this before. You sign the contract thinking you’re getting a team led by people who actually know what they’re doing.
Then the real work starts, and the seniors vanish.
In an era where AI is reshaping how code gets written, what shows up instead is a rotating cast of junior developers — fresh graduates, career shifters, people you never interviewed and whose names change every few sprints. The seniors you met on the sales call? They come back for the status meetings. They review pull requests sometimes. But the person actually typing your production code has maybe eighteen months of experience and probably isn’t running pre-commit hooks of experience and learned your framework last week.
This isn’t a bug. It’s the business model.
The Economics That Make This Inevitable
Here’s the math that nobody puts on the sales deck.
A senior developer in a major outsourcing market costs the agency anywhere from $4,000 to $8,000 a month — salary, benefits, overhead. A junior costs $800 to $1,500. The agency charges you, the client, a blended rate. But the margin isn’t made on the senior. It’s made on the markup between what you pay for “developer hours” and what the junior actually costs.
One senior overseeing four juniors produces a margin that a team of all seniors never could. The agency isn’t being dishonest in their own minds — they’re running a business — the economics of software always come back to margins. The senior is there for architecture decisions and client communication. The juniors do the typing. Everyone in the industry knows this is how it works.
Everyone except the client.
Two Heads, a two-person development shop that’s been building software since 1999, wrote about this recently. They described the pattern with the kind of clarity that only comes from watching it happen for twenty-five years: “You meet two or three sharp, experienced people on the sales call. You sign. Then the work goes to a rotating cast of juniors you never interviewed, and the seniors you met come back only for status calls.”
They’re not wrong. I’ve watched it happen. I’ve had to clean up after it.
The Hidden Cost Nobody Talks About
Everyone focuses on the money. Are you getting billed a senior rate for junior work? Yes, usually. But that’s not the expensive part.
The expensive part is lost context.
Every time a junior developer rotates off your project — and they will, because agencies move people around to balance utilization — something gets dropped. It’s rarely the obvious stuff. It’s the quiet knowledge: why that one API call uses a weird timeout value, which database migration is load-bearing and which one is dead weight, what breaks if you touch the module that looks unused but actually handles three edge cases in production.
After a year of rotation, nobody on the team can answer those questions. Not the juniors who wrote the code — they’re on different projects now. Not the seniors who “oversee” — they were never in the weeds. You end up with software that nobody fully understands — and without proper context retention, you’re building on quicksand, and you’re still paying monthly invoices for the privilege.
I’ve seen this in government projects especially. A system gets built over eighteen months by a rotating team of twelve developers. The contract ends. The agency hands over the codebase. And the internal ICT team opens it up to find a maze of decisions with no documentation, no rationale, and nobody left to explain them. That’s not a handover. It’s a hostage situation where the hostage is your own infrastructure.
The Bus Factor Problem
The obvious fix is to hire one really good senior developer — full-time, in-house, someone who owns the codebase and stays with it. That solves the context-loss problem. But it trades it for something equally dangerous: your bus factor is now exactly one.
That one senior takes a two-week vacation and the roadmap stops. They get sick and production incidents wait. They resign — and they will eventually, because good seniors have options — and the entire history of your product walks out the door on two weeks’ notice.
I’ve lived this one too. When I was managing a small development team, we had one developer who genuinely understood our entire authentication system. He was brilliant. He was also the single point of failure for anything touching user accounts, permissions, or session management. When he left for a private-sector role paying twice what we could offer — and I don’t blame him one bit — it took us three months and two external consultants to fully map what he’d built.
One person who knows everything works perfectly right up until they’re not around. And they will eventually not be around.
What Actually Works
So we’ve got two problems. Big teams lose context through rotation — I’ve written before about why small teams need different tooling — and tiny teams lose context through departure. Big teams with juniors lose context through rotation. Small teams with one expert lose context through departure. What’s the middle path?
The team at Two Heads landed on a deceptively simple answer: two. Two senior developers, both of whom build, both of whom know the entire system. Not a senior supervising juniors — two people who can each do the work and each understand what the other built. Bus factor of two isn’t bus factor of twenty. But it’s enough that one person can get sick, take leave, or move on without taking the entire codebase’s institutional memory with them.
Architecture decisions get made by two people who both know the code. Migrations get planned by two people who both understand what’s load-bearing. When one person is out, the other isn’t reconstructing history from git blame — they were in the room when the decision was made.
Now, the Two Heads model is deliberately small. They take few clients and stay on them long-term. They explicitly say this doesn’t scale like an agency. And they’re right — it doesn’t. But here’s the thing: most organizations don’t need it to scale like an agency. They need a small number of things built well, maintained well, and understood well.
What This Means If You’re Hiring
If you’re a manager or a business owner looking at outsourcing your development work, here’s what I’d tell you — and this comes from years of seeing both sides of the table.
First, ask who’s actually writing the code. Not who’s managing the project. Not who’s on the sales call. Who is typing the commits? Ask for names. Ask to meet them during the evaluation process, not after you’ve signed. If the agency won’t let you interview the developers who’ll work on your project, that’s not a red flag — it’s the entire flag factory.
Second, ask about rotation policies. How often do developers move between projects? What happens when someone leaves? What’s the handover process — not the documented one, the one that actually happens? If they can’t answer these questions with specifics, the answer is probably “whatever is convenient for the agency.”
Third, think about team size as a feature, not a cost. A three-person team where everyone understands the codebase will deliver more value over two years than a twelve-person rotating team. The twelve-person team looks better on a Gantt chart. The three-person team is the one that still works after year one.
Fourth, demand continuity clauses in your contract. Specify that key developers — the ones you interviewed and approved — cannot be rotated off without your consent. This costs the agency something, and they may push back. But if they’re genuinely confident in their senior developers’ ability to transfer knowledge, they should have no problem putting it in writing.
And if you’re on a tight budget and the agency route is your only option? At least go in with your eyes open. Know that the sales team isn’t the build team. Budget for the knowledge transfer that won’t happen automatically. And start planning your internal knowledge retention from day one — because when the contract ends, the agency’s memory of your system ends with it.
The Chess Lesson in All of This
There’s a reason I think about team composition the way a chess player thinks about piece coordination.
In chess, a lone queen is powerful but vulnerable. She can attack anything on the board, but if she’s cut off from her own pieces, she gets hunted down and trapped. The strongest position isn’t one powerful piece — it’s pieces that protect each other, cover each other’s weaknesses, and can step into each other’s roles when the position shifts.
Software teams work the same way. One brilliant developer surrounded by people who don’t understand their decisions isn’t a strong position. It’s an isolated queen waiting to get trapped. The strongest teams are the ones where multiple people understand the system deeply enough to protect each other. Not twenty people. Not one. Probably somewhere between two and five, depending on the size of what you’re building.
The Two Heads approach isn’t the only answer. But the principle behind it — that continuity of understanding matters more than headcount — is worth taking seriously, whether you’re running an agency, managing an internal team, or writing checks for outsourced development.
Because here’s the uncomfortable truth: the senior developer you thought you hired probably isn’t writing your code. And the juniors who are writing it won’t be around long enough to learn from their mistakes. You’re paying for continuity you’re not getting, expertise you’re not receiving, and a codebase that’s slowly becoming a black box you don’t own.
That’s not a development engagement. That’s an expensive way to build technical debt.