The request is small. The membership campaign needs its landing page to stand out, so could the button be orange on that one page instead of the usual blue. It takes four minutes. Somebody adds an inline style, the page ships, the campaign does well, and nobody thinks about it again.
Three years later a developer opens that site to scope a redesign and finds nineteen button styles, four page builders' worth of shortcodes, a plugin that exists to add a countdown timer to one event page from 2024, and a homepage that has to be edited by hand because the automatic version stopped matching what people wanted. There is no single decision in that history you could point at and call the mistake.
Every one of those changes was reasonable when it was requested. That is the part worth understanding. Bad websites do not usually come from bad decisions. They come from a long run of good ones that nobody was counting.
How It Actually Happens
The pattern is consistent enough across organizations that we can describe it as a sequence. It usually runs something like this:
- Year one. The site launches with a template system, a set of components, and rules about how pages are built. Everything is consistent because there has not been time for it not to be.
- Month eight. Somebody needs a layout the templates do not cover. It is genuinely needed and the deadline is real. A one-off page gets built. It works.
- Month fourteen. A different person needs something similar but not identical. Rather than reopen the design question, they copy the one-off page and change it. Now there are two exceptions and no rule covering either.
- Month twenty. A plugin gets installed to solve a problem the theme could solve, because the plugin takes an afternoon and the theme change takes a week. This happens perhaps six more times.
- Month thirty. The staff member who understood the original system leaves. Their replacement inherits the site as it is now, not as it was designed, and reasonably assumes the current state is the intended state.
- Month thirty-six. Everything looks fine from the front. The homepage loads, the branding is consistent enough, members find what they need. The mess is entirely on the other side of the login.
Notice what is missing from that sequence. No villain, no incompetence, no vendor who did a bad job. A series of correct local decisions producing a bad global outcome.
Why Nobody Catches It
Three things have to be true at once for drift to go unnoticed, and in most associations all three are.
The first is that every change is judged on its own merits. Nobody approves the site. People approve requests. A request for an orange button is evaluated on whether an orange button is a good idea for that campaign, which it might well be. It is not evaluated against the question of what happens when eleven other people make comparable requests, because nobody is asked that question.
The second is that no one holds the whole picture. The person who runs the events calendar is not the person who runs the member portal, and neither of them owns the design system, because there is no owner of the design system. There is a marketing lead, an IT director, and an agency, and the space between the three of them is where the drift accumulates.
The third is that the failure is silent. The site keeps working. Nothing crashes. There is no alert for architectural decay, no dashboard that turns amber, no advisory to read. Compare that to a security patch, which announces itself. This does not announce itself until somebody quotes you a redesign number.
What It Costs, Stated Honestly
This is where the argument usually goes soft, so here is the concrete version.
Discovery gets expensive. A redesign on a clean site starts with design. A redesign on a drifted site starts with archaeology. Somebody has to open every template, work out which of the nineteen button styles are load-bearing, and decide what is intentional and what is residue. That discovery is billable, it is slow, and it produces nothing the board can see.
Content stops being portable. Your content is portable when it is structured. When it is embedded in page builder shortcodes and inline styles, it is not content any more, it is markup. Moving it means rebuilding it, and that is the number that makes a redesign quote land higher than anyone expected.
And the shortcut does not save money. It moves it. The savings were real. Four minutes instead of a week is a real saving. What actually happened is that a known, small, present cost got converted into an unknown, larger, future one, payable at a moment you do not control, usually during a redesign or an incident, when your leverage is lowest.
This Is Not an Argument Against Letting Your Staff Edit the Site
It would be easy to read all of that as a case for locking the site down and routing every change through a developer. That would be the wrong conclusion, and we have argued the opposite in print.
The promise that non-technical staff can run a professional website is real. A properly implemented content management system lets a communications coordinator publish a blog post, add a team member, update an event, and change the phone number in the footer without help from anybody. If your staff cannot do those things today, the problem is the implementation rather than the ambition, and it is fixable. That is a different post and a different remedy.
The distinction that matters is between editing content and composing layout. Editing content within a structure is what a CMS is for, and it scales fine. Composing new layouts is a design decision wearing the costume of a content update, and it is the one that compounds. Fifty blog posts do not make a site harder to maintain. Fifty bespoke pages do.
The Boundaries Are the Product
When an organization asks for a site anyone can edit, what they usually mean is a site where nobody is blocked. Those are not the same thing, and the second one is achievable while the first one quietly is not.
A design system that offers eleven components and refuses the twelfth is not restricting your team. It is the reason the site still looks like one organization after three years and forty contributors. The constraint is doing work. It is the least visible thing you paid for and the first thing anyone asks to have waived.
Which leads somewhere uncomfortable for people in our line of work. A vendor who says yes to every request is not being flexible. They are moving the cost of that decision to a future invoice, and it will be a larger one.
What Actually Prevents It
None of this needs a large program. It needs four things that mostly cost attention rather than money:
- A component set with an actual edge. Not a style guide nobody opens. A finite set of components, written down, with the rule that new pages are assembled from them. When something genuinely falls outside the set, that is a decision to make deliberately and add to the set, not a one-off to bury in a page.
- One owner for the system. A person, named, who is accountable for whether the site still hangs together. Not a committee. The job is small in any given month and impossible to do retroactively.
- A question attached to every exception request. Ask what happens if the next eleven people ask for the same thing. Most requests survive that question. The ones that do not are the ones worth handling differently.
- A review on the calendar. Open the templates, count the variants, look at what got added. An hour, four times a year, catches drift while it is still cheap to reverse. Nobody does this, which is why redesigns cost what they cost.
The Part We Should Own
Agencies cause a good deal of this, and it is worth saying so plainly rather than writing a post that blames clients for asking.
Saying yes is easier than explaining why the answer should be no. It is faster, the client is happy that day, and the work is billable. Explaining that a four-minute change will cost eight thousand dollars in three years is an awkward conversation to have with somebody who just wants an orange button before Friday, and the person having it looks obstructive rather than useful.
We have made that trade too, and it was the wrong one. But the agency is the only party in the room who has seen what the site looks like in year four, and who knows what the discovery phase costs. Not raising it is a choice, and the polite version of that choice is what produces the mess.
Find Out How Far Yours Has Drifted
You do not need a redesign to answer this, and you should know the answer before anyone quotes you for one. Give us access to the site and we will count what is actually there: how many distinct button, heading and layout variants exist across your templates, which plugins are doing work the theme should be doing, which pages sit outside the system entirely, and which of your content types are structured rather than pasted markup. What comes back is a list of what would need untangling before a redesign, ordered by what it would cost to leave alone. If the site is in good shape, that is a short letter, and it is worth having on file either way.