For thirty years, getting a website meant letting somebody else describe you

If you have been running a firm for twenty or thirty years, you have a memory of how a website came to exist, and it probably goes something like this.

You decided the firm needed one. You did not know how to get one, and neither did anyone in the office, so you found an agency. They came in, sat down with you for an afternoon, and asked what the firm did and what made it different. Some weeks later a document arrived describing your firm back to you in language you would not have chosen. You read it, thought it sounded a bit grand, and approved it anyway, because they were the experts and you had a business to run.

Then it went quiet for a while. Somewhere in that quiet was a coder. You never met them. Their job was to take the words and the layout and turn them into HTML, then put those files on a server. When you asked how long something would take, the answer came back through the agency, and it was always longer than you expected.

The coder was the visible cost

That arrangement lasted, in one form or another, for a very long time. And for most of it the coder was the part that felt expensive and mysterious, because it was the part nobody in your firm could do or even really assess.

But look again at where the value sat. The coder rendered a definition. They did not create it. By the time the work reached them, the important decision had already been made, in a meeting room, by people who had known your firm for an afternoon.

That decision was how your firm would be described. Who you served, what you were for, which parts of the work to put at the front and which to leave out. It is the most consequential piece of writing a professional firm produces, and it is the piece that was routinely handed to an outside party and then approved with a shrug.

Nobody hid this. It simply did not feel like the expensive part.

The CMS looked like it changed things

Then came content management systems, and WordPress in particular. This was presented, fairly, as taking back control. You could log in and edit your own text. No more waiting a fortnight to correct a typo.

It did change something real. It did not change the thing above.

You could now edit words, but you were editing them inside a structure somebody else had designed, under headings somebody else had chosen, expressing a positioning somebody else had written. The agency’s document was still running the site. What had changed was who did the typing.

And the agency did not go away. They kept the design, the hosting, the plugin updates and the redesign every four or five years, at which point the whole cycle ran again. A new discovery meeting. A new document describing your firm in language you would not have chosen.

What is actually being replaced now

The current story about large language models is that they replace the coder. That is true enough, and it is the less interesting half.

The coder was a cost and a delay. Removing a cost is useful. But if that is all you do, you end up with a faster, cheaper website saying the same borrowed things, and you have automated the least important link in the chain.

The part worth paying attention to is that the definitional work can come back in-house. Not the typing. The deciding. Working out who you serve, what they actually need to know, and what your firm is prepared to claim is now something you can do yourself, iterate on cheaply, and change on a Tuesday afternoon when you realise it is wrong.

That is a return of authority rather than a saving.

The trap in it

There is an obvious way to get none of this.

Ask a model to write you a website and it will produce something that reads exactly like an agency wrote it. Confident, smooth, full of phrases about trusted partners and tailored solutions. It has read thousands of those pages. It is very good at producing more of them.

So the tool will cheerfully hand you back the precise thing you were trying to escape, faster and at lower cost, and you will have gained nothing but speed.

Avoiding that is not a technical problem. It requires somebody in the firm to sit down and answer the questions the agency used to answer, and to keep answering them as the firm changes. Who do we actually work for. What do they need from us that they are not getting elsewhere. What are we saying because it is true, and what are we saying because it is what firms like ours say.

Those are uncomfortable questions, which is part of why they were outsourced in the first place.

What we found doing it ourselves

We rebuilt our own site recently, and wrote up what was involved. The technical side turned out to be the easy part. The hard part was the same afternoon’s worth of questions, asked properly rather than by somebody visiting for the day.

Some of what our old site said did not survive it. It was there because it was the sort of thing firms like ours say, and once we had written down plainly who we work for, it stopped making sense. Our journal changed more than anything else. What we had been publishing were general industry pieces that could have appeared on any technology provider’s website. What we publish now comes out of work we have actually done.

None of that was caused by changing platforms. Rebuilding simply made it unavoidable, because you cannot move a page across without reading what it says.

The question underneath

For most of the last thirty years, the question people asked was who is going to build our website, and the answer was an agency and a coder you would never meet.

The better question was always who decides what it says. That one was harder to see, because it arrived bundled with the technical work and priced as part of it.

It is now unbundled. The building has become cheap enough that the deciding is plainly the valuable part, and it is sitting there waiting for somebody in your firm to do it. Whether that is an improvement depends entirely on whether anybody does.

In case the subject invites the question: we do not build or host websites, for clients or for anyone else. We run cybersecurity and IT for regulated firms. This is only what rebuilding our own site taught us about a question most firms have never had to ask, and the answer to it is not something you should be buying from us either.