Dev shops sell you seniors, then staff the work with juniors

We’ve been building software since 1999. Our own products, and a lot of it for other companies. The most common way the client work goes wrong has nothing to do with code.

It goes like this. 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. By the time something breaks in production, the person who wrote that part has moved to another client, and their context went with them. You’re paying a senior rate for supervision of people learning on your money.

Nobody’s being dishonest. It’s the economics of an agency. Senior people are expensive, so the margin comes from markup. One senior oversees several juniors who do the typing, and that separates the people who understand your system from the people changing it. Everyone at the agency knows this. The client usually doesn’t.

The cost you don’t see on the invoice is lost context. Every handoff drops something: why a thing was built the odd way it was, which migration is load-bearing, what breaks if you touch the part that looks dead. After a year of rotation, nobody can answer those questions, including the team you’re paying. You end up with software no one fully understands.

The obvious fix is to hire one good senior, full-time or contract. That trades the problem for a sharper one. Your bus factor is now exactly 1. They take holiday and the roadmap stops. They get sick and the incident waits. They quit and the product’s whole history leaves on two weeks’ notice. One person who knows everything works fine right up until they’re not around, which eventually happens.

So when we went out on our own, we picked the smallest number that survives one of us being gone: two. Not a senior and a junior. Both of us are senior, both of us build, both of us know the whole system. There’s no one else on the project to lose context to.

Two changes the work in concrete ways. Architecture decisions, build-vs-buy, the scary migration get decided by two people who both know the codebase, not one person guessing or a committee that doesn’t. When one of us is out, the other isn’t reconstructing history from git blame. They were there for it. And two people cover more ground than one: product, infrastructure, and data, owned end to end, instead of one specialist plus a list of things they’ll pick up later.

The fair objection is that two is still small. A bus factor of two isn’t a bus factor of twenty, and we’re not pretending otherwise. The claim is narrower. Two people who both know your system beats ten where only one ever did, and that second case is what most teams turn out to be once you look past the org chart.

The real constraint is the flip side. With no juniors underneath us, we can’t run many clients at once. This doesn’t scale like an agency, by design. So we take few clients and stay on them, building when there’s a roadmap to move and keeping things alive when there isn’t. No rotating team, no handoff, no senior names attached to junior work.

It has to work on Monday and still work next year. After more than 25 years of watching the alternative, it’s the only model we’ll put our names on.