The maths on an in-house dev team changed.

We have written elsewhere that our prices did not fall when building got faster, because the part that got faster was never the part being paid for. That holds for a website build and we would say the same thing again.

Systems are a different question, because the thing being compared is not another agency quote. It is the annual cost of a function the business currently carries.

What that function costs

A Technical Lead and two or three developers is a substantial annual commitment before anything is built. It is largely fixed, it does not flex when the roadmap is quiet, and recruitment for it is slow and competitive.

The alternative many businesses take is a larger agency, where the day rate reflects an operation with account management, delivery management and a floor of people to keep occupied. You are funding that structure whether or not it touches your project.

You are not comparing two quotes. You are comparing a project against a fixed annual cost that does not flex.

Where the saving actually is

It is in overhead you no longer need to carry, not in the project being cheap. A small studio has no account layer, no bench, no recruitment cycle, and no fixed cost sitting there in a quiet quarter.

The trade is real and worth stating plainly. You give up having people in the building. What you get back is a lower fixed cost, direct access to whoever is making the decisions, and no layer between you and the work.

Where this argument does not apply

If software is your product, you need your own team and no external studio is a substitute. If you are regulated in ways that require people inside the building, same answer.

The argument applies to businesses who employ developers to run the systems they operate on, rather than to build the thing they sell. That is a much larger group than the first, and most of them arrived at that structure when there was no realistic alternative.

On tooling costs

The tooling that makes this possible will get more expensive. It is priced to grow and it would be naive to plan otherwise.

The economics still hold, because tooling is a small fraction of what a permanent team costs and the gap is wide. And the quality argument does not depend on the tooling being cheap. It depends on there being room to review properly, iterate, and build something twice when the second version is better.

The uncomfortable part

This is the part the industry is not saying out loud, so I will. For new project work, I think it is becoming very hard to justify commissioning a team of people to write code from scratch. Not impossible, and not in every case, but hard. That is my view rather than a neutral observation, and I would rather state it plainly than hint at it.

It is a real shift with real consequences for people, and pretending otherwise helps nobody. Two things it does not mean. Experience matters more, not less, because the cost of a bad structural decision has risen now that so much can be built on top of one so quickly. And it applies to new projects rather than to everything: supporting a system somebody has lived with for years is a different job, done by different people, and we have written about that separately.

If you take one thing

Work out what your technical function costs annually, all in, including recruitment and the quiet quarters. Then ask what you actually got built last year. If those two numbers look uncomfortable next to each other, the structure is worth revisiting.

Three more
worth the time.