A client says they need a website.
Fine.
Five or six pages. It needs to look good. There will be video, some audio, a YouTube channel and a few things they would like to change themselves.
That sounds straightforward.
Give that brief to a competent developer or an AI system and a sensible answer appears quickly: keep it lean. Use something fast. Embed the video. Do not build a huge publishing system until there is evidence that one is required.
That is good advice.
It can also be completely wrong.
Because “I want video on the site” does not tell you whether somebody wants a video on a website or wants to run a publishing operation that happens to have a website at the front of it.
Those two things can look remarkably similar on launch day.
Six months later, they are completely different systems.
The page is the visible bit. The workflow is the job.
Web projects often begin with the things people can see.
Homepage. About page. Contact. Video. Audio. Blog.
So naturally the conversation moves straight into design, frameworks, hosting and how many pages there are.
The more useful questions are often much less glamorous.
Who creates the content? How often? Who uploads it? Does it need drafts? Scheduling? Categories? Tags? Search? Archives? Does media live on the site or somewhere else? Does one thing need to become a website post, YouTube video and podcast episode? What happens when there are fifty items rather than five?
A website that changes twice a year and one that publishes three times a week can have almost identical navigation.
They are not the same product.
That distinction is why I increasingly want to understand what happens after the site is launched before I become attached to the technology used to build it.
A CMS is not automatically more professional
There is a strange assumption in web work that a serious website naturally comes with a content management system.
Does it?
If nobody is publishing anything, a CMS can become an expensive little room attached to the back of the website that nobody visits.
It introduces another interface, another set of permissions, another thing to update, another place for complexity to accumulate.
Sometimes that is exactly what the project needs.
Sometimes the entire content-management requirement is: “Can we change the phone number ourselves?”
Those are not equivalent problems.
A simple site is not amateur because it does not have a large admin area. If the site mostly exists to represent a business and changes occasionally, reducing the machinery may be the more professional choice.
The aim is not to build as much system as the budget will tolerate.
It is to leave the client with the right amount of system for the work they are actually going to do.
The stack should be a consequence of the operation
Developers are very good at becoming emotionally attached to the technology question.
Which framework? Which CMS? Headless? Traditional? Static? Server-rendered? Custom? Hosted? Self-hosted?
All reasonable questions.
They are also downstream questions.
If I choose the stack before I understand the operation, I am doing architecture by enthusiasm.
I have done that. Most developers have. A tool is elegant, new or simply enjoyable to use, and suddenly every client problem develops a suspicious resemblance to the problem that tool solves best.
The safer order is boring:
Understand the job first.
Choose the machinery second.
That does not mean one platform is for simple sites and another is for complex ones. Modern tools overlap enormously. Astro can power content-driven sites and connect to external content systems. WordPress can be used as a traditional publishing platform, a headless backend or far more than a basic blog. Next.js can be used to build almost anything, which is both useful and dangerous.
The point is not which tool wins.
The point is that the brief should decide the architecture rather than the architecture quietly rewriting the brief.
“I want video” can mean four completely different jobs
This is why apparently precise requirements often are not precise at all.
“I want video on the website” might mean one showreel on the homepage that changes once a year.
It might mean a regularly updated video library.
It might mean every video needs its own page, transcript, metadata and related audio.
Or it might mean the website is the central publishing record for an operation that also sends content to YouTube, podcast feeds, newsletters and social channels.
One sentence. Four architectures.
The same thing happens with the word blog.
For one business, a blog means six news posts a year.
For another, the content is the business: editorial workflow, drafts, authors, media, categories, feeds, search, archives and years of material that still has to make sense after the homepage has been redesigned three times.
Calling both things a blog does not make their operational requirements equivalent.
Ask what happens on Monday morning
The question I like now is very simple.
What happens on Monday morning after launch?
Show me how you imagine adding the next video.
Where does the audio come from?
Who writes the description?
Who publishes it?
Does somebody else need to approve it?
What if the title changes?
Where should a visitor find it six months later?
Those questions can completely change the technical answer while containing almost no technical language at all.
That is why consultation is not merely the friendly bit before developers start doing the real work.
Often, it is where the architecture is actually decided.
Do not build a publishing operation for somebody who does not want to publish
Once you know how to build flexible systems, overbuilding becomes surprisingly easy.
Custom content types. Editorial roles. Preview environments. Media pipelines. Structured metadata. Search. Scheduling. Clever integrations.
All excellent features when the work requires them.
All slightly ridiculous if the owner wants to change the Christmas opening times once a year.
Flexibility has a maintenance cost. Somebody has to understand it. Somebody has to keep it working. Somebody has to pay for it.
Being able to build a complex system is not evidence that complexity is appropriate.
Sometimes the most professional architecture is the one with fewer moving parts.
And do not build a brochure for somebody who is about to become a publisher
The reverse mistake is more deceptive because it can look excellent at launch.
The site is fast. The design is clean. The video plays. Everybody is delighted.
Then somebody asks how to add next week's episode.
Then where the audio version goes.
Then whether it can be scheduled.
Then how to group the archive.
Then whether another person can upload drafts without publishing them.
The elegant brochure site slowly acquires a publishing system one emergency at a time.
This is how “simple” websites become complicated systems by stealth.
The original build may not have been technically bad. It may simply have solved what the site needed to look like on launch day instead of what the organisation needed to keep doing afterwards.
The architecture should follow the work
I still care enormously about design, performance, accessibility and maintainability.
But before I decide how clever the stack should be, I want to know what job the website is expected to continue doing.
Does it mostly sit there and represent the business?
Or is somebody operating it every day?
Is content a handful of pages?
Or is content the product?
Is media decoration?
Or is media the workflow?
Those answers are more important than whether somebody arrived asking for WordPress, Astro, Next.js or anything else.
So the title is deliberately a little provocative.
There are excellent reasons to run a CMS.
“Because websites have CMSs” is not one of them.
And if you are genuinely publishing, there are equally good reasons not to pretend you are building a simple brochure simply because the homepage has only five links.
The architecture should follow the work.
Everything else is tooling.