You wanted to change a headline. Not redesign a page, just swap one line that was wrong. Three weeks later it went live, and somewhere in that window it cost two thousand dollars, because the headline was hard-coded into a custom template and only the agency that built the site could open the file.
That two thousand dollars went to someone, and the same someone chose the architecture that made it cost that much. If you have ever searched for how to update your website without a developer, this is why you could not. This is my industry, so I will say it plainly: a website only its builder can change is a website that keeps paying its builder. Developer dependency is the agency's business model, and it has very little to do with the platform.
This is the second of the seven COMPASS pillars: O, Operable by Marketing. It asks one question about your website. Can the team who owns it actually run it?
Operable by Marketing means a marketing team can create pages, update content and launch campaigns on their own website without raising a developer ticket. It is decided by how the templates and components were built, not by which content management system was chosen.
Nobody wrote it into the requirements
Think about the original RFP for your website redesign. You probably specified the page count, browser support, the accessibility standard, the hosting environment and the launch date. But I bet nobody said that the marketing team must be able to publish a new page, unaided, on the day they need it. I have read a lot of these documents and it is rarely there.
This omission alone sets the stage for what you end up with, because the site is costed and built exactly to spec, and nobody is answerable for a requirement that was never written down.
The people best placed to notice that gap have the least reason to raise it, and I don't think this is usually malice, more the commercial reality of a tender. A lowest-price bid scopes the build to the tightest reading the RFP allows, and as a practitioner I can tell you a rigid template is cheaper and faster to build than a flexible one. But nobody in this market gets bonused on how little their client needs them next quarter.
This is not a local complaint. When Netlify surveyed 150 marketers in 2024, 87% wanted more control over web content without needing a developer. Netlify sells a cure for that, so read it as directional.
I know how common this is because we often inherit these sites. When a client moves to us from a previous vendor we open the build and list what their marketing team can change without us. That list is almost always shorter than what a properly configured CMS can support: headlines sitting in template files rather than content fields, layouts that accept only the arrangement they were drawn for, and no end-user documentation because it was never scoped. The site then ages in plain sight, with a team who can see exactly what needs changing and cannot reach the marketer-friendly controls that would let them change it.
What this actually costs
The fees are the smaller part: three thousand dollars for a new service page, eight hundred for a headline, a maintenance retainer that buys availability rather than autonomy.
The real cost is speed. Today's marketing cycles run weekly, so you launch on Monday, read the data on Wednesday and should ideally optimise your campaign page by the end of the week. A website needing a fortnight and a purchase order to change one line cannot keep that pace, so the team stops trying. Campaigns get built on landing pages nobody has to ask permission for, and the website quietly drops out of the marketing mix.
The lag costs you more than time. It costs you standing, and that is harder to win back. When leadership asks why the landing page still carries last quarter's proposition, "we're waiting on the agency" is not an answer that reflects well on you, because it is your website and everyone in the room expects that you own it.
Build a website your marketing team can update
Changing platform rarely fixes developer dependency on its own, because most modern CMSes can be built for a marketer to run, or built so every change goes through a developer. What decides it is agreeing what your team must do without help, then writing that into the requirements.
Duke-NUS is the clearest example. Their estate runs past a thousand pages, and every department head and board member wanted a say in how it looked. A full sitewide rebuild would have consumed the budget before design even started, and produced exactly the trap I have been describing.
Instead of building each department a fixed template, we took all their requirements together, worked out what they had in common, and built them as a library of Sitefinity components that compose into whatever a page needs. That is what COMPASS decides before anything is designed. More than a hundred visitors and staff told us what the site had to do, and that fed the component set rather than finished layouts. A department that wants something that nobody expected in 2022 can still assemble it from the brand-compliant reusable components, instead of commissioning a template, and push the page live themselves.
That decision cost us money, because every page they build themselves is a page they are not paying us to build. But they have stayed with us for years since, by choice rather than by lock-in, and I would rather win the work that way.
Four questions to ask about your current site
You can run these in about twenty minutes.
Can a marketer publish a new page unaided? Not edit an existing one. Create a new page, choose a layout, publish it. If that needs a developer, your templates are too rigid.
How many change requests last quarter were content, not code? If most of your tickets are copy, images and new pages, you are paying developer rates for work your own team should own.
What happens when someone changes an image? If the honest answer includes "it might break the layout," your components are not safe to use, and your team has already learned not to touch them.
Does current training documentation exist? Not a handover call from two years ago. A document your next hire could learn from.
Three or more uncomfortable answers and the problem is architectural. No amount of CMS training fixes a site that was never built to be operated.
So the fix starts at the next RFP. Ask any agency bidding for the work what you will be able to change without them, put the answer in the scope, and test it at user acceptance rather than six months later. A good partner answers that happily.
FAQ
Q: What does "operable by marketing" mean for a website?
A: It means the marketing team can create pages, update content and launch campaigns without raising a developer ticket. Operability is an architectural decision made before the build: modular templates, editable components, a CMS matched to the team's real skill level, and current training documentation. It is one of the seven pillars in COMPASS, Construct Digital's website strategy framework.
Q: Why does every change to our website need a developer?
A: Usually because content was hard-coded into custom templates rather than exposed as editable fields, and because nobody specified marketing self-sufficiency as a requirement before the build began. This is an architecture problem rather than a training problem, so it cannot be fixed with more CMS lessons after launch.
Q: Should we replace our CMS to fix this?
A: Not necessarily. The platform matters far less than how the templates and components were built on it. A well-structured WordPress or Sitefinity build can be entirely self-serve, and a poorly structured build on any platform will not be. Audit the template architecture before concluding the platform is at fault.
Q: How do we stop this happening on the next website project?
A: Write operability into the requirements. Specify what marketing must be able to do unaided, name it as an acceptance criterion, and test it during user acceptance rather than after launch. Ask any agency bidding for the work what you will be able to change without them, and put their answer in the scope.
What to do next
If your website needs a developer for work your own team should own, nobody chose that. It was left out of the requirements and built in by default. That makes it fixable, but it gets fixed in the architecture, because the constraint sits in how the templates were made, not in how well your team was trained.
Run those four questions against your website. If the answers are uncomfortable, score your website against all seven COMPASS pillars and find out where else the foundations are thin, or read how COMPASS settles operability before a line of design work starts.
Score Your Website
Twenty-one questions, about six minutes. See how your website scores against the seven pillars of COMPASS, and get a pillar-by-pillar report you can put in front of leadership.