The dominant model in software services looks like this:
- Senior architects and lead engineers scope a project.
- A build team — often bigger, often junior — actually writes it.
- After go-live, the build team disbands.
- A support team — different people, sometimes different geographies — inherits the system with a runbook and a wiki page.
The economics of this are easy. Senior time is expensive. Junior time is cheap. Support time is cheaper still. Firms that structure delivery this way can bid lower, and often do.
The quality costs of it are harder to see. We’ve spent twenty-five years watching them show up.
Where the hand-off hurts
The support team can’t fix incidents at the level the build team introduced them. A bug that took the original architect two hours to introduce takes a support engineer two weeks to find, because the architect knew exactly which idea in the design was fragile and the support engineer didn’t inherit that knowledge.
Runbooks capture procedures, not judgment. “If service X returns 503, restart service Y” is a fine runbook entry. But the reason service Y needs restarting is usually deeper — a race condition that fires under a specific data shape — and no runbook captures it. The build team, if it stayed, would have quietly fixed it. The support team documents it and lives with it.
The build team never gets negative feedback about how they built. If you’re a senior engineer whose systems always get handed off, you never find out that your favourite pattern is a nightmare to operate at 3 AM. You just keep using it on the next project.
The customer builds two relationships instead of one. They trust the build team, learn the support team, and eventually realise the two aren’t talking to each other about their system. That erodes into the vendor relationship over time.
What we do instead
The same senior team stays with a project from discovery through post-launch operation. That’s not a marketing claim — it’s how we’ve structured every long engagement since we started.
Concretely:
- The lead engineer who scoped the project is the lead engineer who ships it and the lead engineer who supports it. Sometimes for years.
- Support is a 20–30% capacity commitment from the build team, not a hand-off. After go-live we don’t shed the team; we resize it. The seniors stay embedded.
- The build team owns the on-call rotation for their system. Nobody gets to introduce a bug they don’t have to answer for.
- We don’t replace people out of the client’s team mid-engagement unless the client asks. Attrition happens; when it does, we introduce a successor with three weeks of overlap, not three days.
What it costs us
Two things.
It’s more expensive per hour than the industry standard, and we say so. Senior people don’t scale by pyramiding juniors under them. If you want the model, you pay for the model.
We can’t take on infinite work at once. We have to say no more often than a bigger firm would. That’s a business constraint, not a virtue — but it does mean the projects we do take get the attention we promised.
What we get from it
- Systems that are still running, healthy, ten and fifteen years later. Some of our MPKV work has been in production since 2007.
- Clients that stay for decades. Roughly two-thirds of our current revenue comes from relationships older than five years.
- Engineers who improve, because they see what happens to the code they wrote three years ago and get to make it better.
There are legitimate reasons to run a services firm the other way. Scale is one; specialisation is another. This just happens to be how we’ve chosen to run this one, and we’ve come to believe it’s better software — not just better economics for us — over any timeframe longer than eighteen months.
If that fits how you’d like your project run, we’d like to hear about it.
