What 'managing your own website' actually means.
I build sites you can run without calling me for every small change. Here's how I think about that, and what it looks like in practice.
One of the most common frustrations I hear from business owners is that they feel held hostage by their web developer. Every small update, a new photo, a changed price, a different set of opening hours, costs money and takes far longer than it should. You send an email, you wait two days, and you get an invoice for fifteen minutes of work.
That's not a technology problem. It's a design decision, and usually a bad one. The site was built to be handed back to the developer, not run by the person who owns it.
What ownership actually looks like.
A website you own is one where you can change the things that change, without needing to understand a single line of code. Prices, team photos, blog posts, event dates, opening hours, the banner that says you're closed between Christmas and New Year. All of that should be editable through a simple screen, not a code editor, and definitely not an email to me.
For most businesses that means a proper CMS, a content management system, built into the project from the first day. Not bolted on afterwards. The admin screen should be plain enough that a new colleague can find their way around it in a single morning, without a manual and without a training day. You pay a little more for that up front, and you earn it back in every hour you don't spend waiting on a developer.
A site you can't update is a site you don't own.
The things you should be able to change yourself.
When I hand a site over, here's the kind of thing I expect you to do without me:
- Edit the text on any page, from the homepage headline down to the small print in the footer.
- Add, change or remove products, including their prices, photos and descriptions.
- Publish a blog post or a news update with images, and have it show up in the right place automatically.
- Swap out photos across the site without worrying about sizes or file formats.
- Update opening hours, contact details, and that one banner you always need to change around the holidays.
None of that should feel risky. A good build makes it hard to break the layout by accident, so you can edit with confidence instead of hovering over the save button hoping nothing falls over.
Where I draw the line.
Some things genuinely need a developer, and I'm honest about that. Adding a brand new section to the homepage, connecting a new payment provider, changing how the navigation behaves, building a custom booking flow. That's real work, and it's fine to pay for it. The point isn't to write developers out of the story. It's to make sure you're not paying developer rates to change a phone number.
I also build things so the everyday edits and the structural work stay well apart. You get a clear, safe space for content. The parts that can actually break the site live somewhere you won't wander into by accident.
The handover is the part most people skip.
This is where a lot of projects quietly fall apart. The site launches, everyone's happy, and then nobody writes down how to actually run it. Six months later the owner is guessing, or calling the developer for something they were always allowed to do themselves.
So I document every project I hand off. A short written guide covering what's editable and where to find it, plus a screen recording where I walk through the real admin: updating a real page, adding a real product. Ten minutes of video you can rewatch, or hand to whoever joins the team next year. It's a couple of hours of my time that saves you a stack of small invoices.
A question worth asking before you sign anything.
Before you commit to a new website, ask whoever's building it one thing: show me how I'd change the homepage text and add a new product. If they can demo that in five minutes, in the actual system you'll be using, that's a good sign. If they get vague, or explain that those are 'small change requests' you'll submit to them, you now know exactly how the next three years are going to go.
You're not looking for a website you can code. You're looking for one you can run. Those are two different things, and the difference is mostly decided on day one.