

The bottleneck in a project was never how fast anyone could type. It was knowing which of several plausible answers was the right one.
There is a particular kind of software problem where five different approaches all work. They all pass the tests, they all do what the brief said. Four of them will cause somebody grief in about eighteen months.
Knowing which one is the fifth is the job. It always was. Producing the code was the easy bit even when it was slow.
We have written elsewhere about the client who came to us with an API integration nobody could support. Seven hundred thousand permissions, one previous author, no documentation and no appetite from anyone to touch it.
Nothing about that code was incompetent. It worked. It had simply been built by someone optimising for getting it done rather than for anyone having to live with it afterwards. Every individual decision was defensible. The accumulation was not.
Every decision was defensible on its own. Together they made something nobody could safely touch.
It is pattern recognition about consequences. Having watched enough builds age badly, you develop an instinct for the decision that will be expensive later. That instinct is not available from anywhere except having got it wrong a few times.
It is also knowing when a client’s request is not the thing they need. Someone asks for a feature. What they are describing is a symptom of a structural problem two levels down. Build the feature and you have papered over it. Ask two more questions and you find the actual thing.
This is the part people miss. When producing code was slow, bad architectural decisions were partly self-limiting, because you could not build very much on top of a poor foundation before running out of time.
That brake has gone. You can now build a great deal on top of a poor foundation very quickly indeed. Which makes getting the foundation right more valuable, not less, and makes reviewing the work properly a bigger part of the job than it used to be.
When you commission a project, ask who is making the structural decisions and how many builds they have watched get old. That is the question that determines what the thing costs to own, long after the launch date stops mattering.

We build on WordPress and will carry on doing it. But a lot of businesses are running an operational system on a publishing tool, and eventually it shows.
How we build has changed considerably in the last couple of years. What it costs has not, and I want to be straight about why that is.
One website on a flat monthly retainer is a reasonable decision. Ten websites on the same flat retainer is somebody else’s business model, and you are funding it.