A queue for every small change
Someone spots a typo on the services page. It goes into an email to the developer, who replies a few days later with a quote or a promise to look at it. Meanwhile a price has changed, a new team member has started and the Christmas opening hours need adding. Each one is a separate email, and some get forgotten.
The result is a site that is always slightly wrong, and a team that has stopped suggesting changes because the effort is not worth it.
Why your site is locked up
There are a few common reasons, and knowing which one applies changes the fix.
| How the site was built | Why staff cannot edit it |
|---|---|
| Hand-coded HTML files | There is no editing screen at all; every change is a code change |
| WordPress with content hard-coded in the theme | The admin area exists but the text lives in template files |
| Page builder with complex layouts | Staff can edit, but one wrong drag breaks the page, so nobody dares |
| Custom system with no admin | The developer built only what the public sees |
| Staff have no login, or only one shared one | The tools exist but nobody was given access or shown how |
The last one is more common than people expect. Sometimes the site is perfectly editable and nobody in the business was ever handed the keys.
What the waiting costs
Each small change carries a developer's minimum charge and a delay. Over a year that adds up to money spent on edits that should take a member of staff a few minutes.
The bigger cost is what does not get done. Nobody writes the new service page or updates the case for a sector you have started winning work in, because it has to go through someone else. The site falls behind the business, and marketing ideas die at "we would have to get the developer to do it".
How we make the site editable
- Work out what your team actually changes. Usually it is a short list: services, team, prices, opening hours, news, case examples and job adverts.
- Model that content as structured fields rather than free-form pages. A team member is a name, a role, a photo and a short bio, not a block of formatted text someone has to lay out.
- Build page templates that pull from those fields, with the layout locked. Staff fill in the boxes; the design stays consistent.
- Use WordPress with custom blocks and fields in most cases, because staff can learn it and you are not tied to us. For larger sites we may suggest a headless system such as Strapi or Sanity.
- Give each person their own login with the right role, so an editor can publish news without being able to break the site settings.
- Write a short guide in your own terms, with screenshots, and walk your team through it.
If the current site can be adapted this way, we adapt it. If the content is so tangled into the code that separating it would cost more than rebuilding, we tell you that and why.
What changes day to day
When a price changes, someone in the office changes it. New starters appear on the team page the week they join. Marketing can publish a page for a campaign without a quote. Developer time is kept for the work that actually needs a developer, like new features or integrations.
Is your team stuck behind a developer?
- Small text changes are sent to someone outside the business
- Nobody on staff has a login to the website
- Staff are afraid that editing a page will break it
- The site has visible errors that have waited months for a fix
- Marketing plans stall at "we need the website updated"
- You are paying for edits that take minutes