The month-three problem
Here is a pattern we see a lot.
A company launches a new site. It looks great. Everyone is happy. Then three months pass and it is quietly out of date. Old prices. A job posting that closed in March. A case study nobody added.
Nothing broke. The site just stopped being tended, because tending it meant filing a ticket and waiting.
Why launches feel like endings
Launch is a real moment. There is a date, a party, a post. It is easy to treat it as the finish line.
But a website is not a poster. It is closer to a shop. Somebody has to change the window.
If the only people who can change the window are booked six weeks out, the window stops changing.
What editable actually means
Plenty of sites claim to be editable. Fewer are. Here is the difference. Ask these four questions about yours.
- Can a marketer change a headline without asking anyone?
- Can they add a case study without a developer?
- Can they swap a photo and have the layout still hold?
- Can they do it on a Friday afternoon without worrying?
If any answer is no, that is where your site will go stale first.
The ticket test
There is a quick way to find out how bad it is. Go and look at your ticket queue.
Count how many are just content. A word change. A new logo on the client list. A price update.
On one project we counted forty-one over six months. Every one needed a developer and a release. That team was not slow. They were stuck behind a wall the site had built for them.
What we hand over
When we build a site, the launch is one part of it. The rest is the part that keeps working.
- A content model. The things you publish, set up as things rather than as markup.
- A component library. Pieces your team can rearrange without breaking the design.
- A speed budget. Numbers we check on every build, not a report at the end.
- A training session. An hour with the people who will run it, recorded.
Then thirty days of support, because the real questions turn up in week two, not week one.
What goes stale first
Sites do not rot evenly. Some parts go off much faster than others.
- Prices and plans. Always first.
- Team pages, the moment somebody joins or leaves.
- Client logos and case studies.
- Anything with a year in it, including the footer.
If those four are hard to edit, your site will look neglected within a year, however good it looked on launch day.
Who should own it inside your company
Most companies skip this question, and it causes more staleness than any technical decision.
Somebody needs to own the site. Not a committee. One person who can decide a page changes and has the access to change it.
It does not have to be a big job. An hour a week is usually plenty. But if it belongs to everyone, it belongs to nobody, and it will sit untouched until it gets embarrassing.
How to buy this properly
If you are hiring someone to build a site, ask two questions before you sign.
Who can change the homepage headline after launch? And what happens when we want a page type nobody planned for?
Vague answers to those are expensive. You will pay for them every month for years.
Worth remembering
In four lines
- The site is not the deliverable. The system behind it is.
- Count the content tickets in your queue. That is your real problem.
- Ask who can edit the homepage before you sign anything.
- A site nobody can update starts dying at about month three.
Questions we get asked
Is a page builder enough?
Sometimes, for a small site. The trouble starts when everyone can change everything, because pages drift apart fast. We would rather give you fixed pieces to rearrange than a blank canvas.
How long does training take?
About an hour, recorded so new people can watch it later. If it needs longer, we built it too complicated.
What if we already have a site we cannot edit?
You usually do not need a rebuild. Often we can move the content that changes most into an editable layer and leave the rest alone.
Read next
Working on this yourself?
We help teams sort this out for a living. Tell us what you’re building, or see how it went for other people.