Nobody is getting swapped out.
How we build new things has changed considerably. Who looks after the things we have already built has not, and will not for a long time yet.
We have a development team in India who have worked with us for years. They still support the systems we built together, and that is not a transitional arrangement while we phase them out. It is the arrangement.
I have been fairly direct elsewhere about what has changed in commissioning new project work. It would be dishonest to write that and leave the impression that everything human has been swapped for something automated. It has not, and the reason is worth explaining.
Two different jobs
Building something new and supporting something that already exists look similar from the outside. They are not the same job at all.
A new project starts from intent. You are deciding what the thing should be. Support starts from history. You are working out why the thing is the way it is before you dare change anything, and most of that reasoning was never written down.
The code tells you what it does. It rarely tells you why, and why is the part that stops you breaking something.
What lives in people rather than in code
On a system that has been running for six years, somebody knows that a particular field is handled oddly because of a supplier integration that changed in 2021. Somebody knows which part of the codebase looks redundant but is load-bearing for one client who does something unusual. Somebody knows which change caused an outage two years ago and what was learned from it.
None of that is in the repository. It is in the heads of the people who were there. Replace them and you do not just lose capacity, you lose the reason behind a decade of decisions, and you find out which ones mattered by breaking them one at a time.
How it actually works here
New projects are designed and built the way I have described elsewhere, with me across every part of it. That is where the shift has happened and I am not going to pretend otherwise.
Existing systems stay with the people who know them. When a client we built for in 2019 needs something changed, it goes to the team who built it, because they will do it faster and more safely than anyone starting from a cold read of the code.
That split is not a compromise I am apologising for. It is the right allocation of two different kinds of knowledge, and I expect it to hold for years.
Why this should matter to a client
Because the question that decides what a system really costs is not what it costs to build. It is who will still understand it in three years.
A studio that has cleared out everyone who built the previous generation of work has quietly made every one of those clients somebody else’s problem. We would rather not be that, and continuity is a large part of why clients stay with us for seven and eight years at a time.
If you take one thing
When you commission anything substantial, ask who supports it in year three and whether that person will have been anywhere near the original project. The answer tells you more about the real cost of ownership than the quote does.
Three more
worth the time.
A website build costs what it costs, and we have written about why. Replacing a six figure internal function is a different calculation entirely, and that one has genuinely moved.
Keyword density is dead and nobody held a funeral. What earns visibility now is the thing we were always told was too expensive: writing something worth reading.
It isn’t purism, and it definitely isn’t cheaper for us. It’s that a template quietly makes you design the content to fit the box.