Earlier this year I found myself reviewing a website brief that looked perfectly normal at first glance. There were pages, content requirements, design notes, development requirements and a launch window. Nothing about it was unusual, which was probably why it bothered me. The brief described the website that needed to be built, but said very little about what would happen to it once people started using it.
That is a strange gap because most websites do not become difficult on launch day. They become difficult three months later, when a campaign page needs changing, a plugin update affects a template, analytics tags have multiplied or nobody remembers why a particular section was built in a certain way. The launch is the visible milestone, however the real cost of a website usually appears during the months of ownership that follow.
I started thinking that the brief needed to describe the operating life of the website, not just the initial build. That does not mean turning every project into a heavy documentation exercise. It means being honest about who will update the site, how often that will happen, what parts of the site are likely to change and which decisions should be made easier for the people maintaining it.
Starting With What Happens After Launch
The first question I now ask is not only what the website needs to contain. I also want to know what will keep changing. A services page might be fairly stable, while case studies may be added every month. A landing page template might be used repeatedly by marketing, while the main navigation may only change once a year. Those differences should affect how the site is designed and built.
When those details are ignored, maintenance becomes accidental. Editors end up using whatever page builder controls happen to exist. Developers get pulled back into small changes that could have been handled through a better content model. The business starts treating the website as if it is fragile, not because the technology is weak, but because the original build did not properly account for everyday ownership.
I have seen this happen most often in WordPress projects. WordPress gives people enough freedom to manage content, but that freedom can quickly become confusing if the structure underneath has not been thought through. A client might technically be able to edit everything, while practically being nervous about touching anything because one wrong change could affect the layout.
That is why maintenance belongs inside the brief. If a team is expected to manage content themselves, the design and development decisions need to support that expectation. If the site will be managed mostly by developers, that should also be clear. The problem is not either model. The problem is pretending both are true at the same time.
Writing Down The Parts That Usually Break
I have started treating recurring website problems as brief requirements. If a site regularly needs campaign pages, the project needs a campaign page approach. If the team frequently adds staff profiles, those profiles need a proper content structure. If landing pages are going to be duplicated and adjusted, the blocks and patterns need to survive that behaviour without becoming a mess.
This is not glamorous work, but it changes the quality of the project. A website that launches with a clean visual design can still become difficult if every future change requires guesswork. A website with a slightly simpler design, but clearer content rules, may be far easier to live with over time. That trade-off is not always visible during the pitch stage, but it becomes obvious during ownership.
I also like documenting the decisions that are likely to be forgotten. Why was a section built as a reusable block? Why is a page locked down? Why are some fields editable and others controlled by the theme? These are not long essays, but short notes that help the next person understand the original thinking without having to reverse-engineer the build.
The useful part is that this documentation often improves the build while it is still happening. If I cannot explain why a section should be editable in a certain way, the structure probably needs rethinking. If the client cannot explain who will be responsible for updating an area, that part of the site may need a more careful handover.
Making Maintenance A Commercial Conversation
Maintenance also needs to be discussed commercially. A business might want a website that can change quickly, but that usually requires more work upfront. Flexible templates, reusable blocks, editor guidance and careful testing all take time. They are valuable because they reduce future friction, but they should not be treated as invisible extras inside the build.
This is where a more honest brief helps everyone. The client can decide where flexibility is actually worth paying for. The development team can make cleaner decisions because they know which parts of the site need to evolve. The project manager has a better way to explain why certain areas take longer than a static design might suggest.
A website that is expected to change every week should not be planned in the same way as a brochure site that changes twice a year. The technical decisions, testing process and handover should reflect that. Otherwise the site may look finished at launch but still be badly prepared for the way it will be used.
Retrospective Thoughts
I think the best briefs in 2024 are starting to describe responsibility as much as output. They still need page lists, design direction and technical requirements, but they also need to explain what the business expects from the website after launch. That is where a lot of poor decisions can be avoided early.
The point is not to make every website larger or more complicated. In many cases, the right answer is to reduce flexibility because too much control creates confusion. In others, the right answer is to invest more in reusable structures because the team will need them every week. The difference depends on how the website will actually be maintained.
That is the part I keep returning to. A website brief should not only describe the thing being delivered. It should describe the conditions the website has to survive. Once that is part of the conversation, the build becomes easier to judge because the question is no longer just whether the site can launch. The question is whether the site can be lived with.