You should be able to edit your own website

Your prices changed last month. Or the opening hours did, or you added a service. The website still shows the old version, because changing it means finding the person who built it, waiting for a reply, and paying an invoice for ten minutes of typing. So the wrong hours stay up a little longer, and a customer stands outside a closed door because your own website told them to.

It is your business, but it is not quite your website. This post is about why that happens and why you do not have to accept it.

The dependency is a choice, not a law of nature

Most business sites can only be maintained by whoever built them. That is rarely malice. Developers build with the tools they know, and those tools tend to be ones only developers can drive. There is also a quieter reason: maintenance is billable, and a site the owner cannot touch produces a steady trickle of small invoices forever. The developer is not evil. The incentives are simply not aligned with yours.

A site can instead be built for handover from day one: content stored in a form you can read, changes you can make and undo yourself, and a written guide for doing both. That is a decision made at the start of a project, not a feature bolted on at the end. It is worth asking any developer about before you hire them, including me.

Your content is just text, so store it as text

The sites I build store every page as plain text in a simple format called Markdown. Rather than define it, here is a real sample of what a page file looks like:

## Opening hours

Open **Tuesday to Saturday**, 9am to 5pm.
Closed on public holidays. [Get directions](/directions)

On the live page, that becomes a heading reading “Opening hours”, a sentence with the days in bold, and a link to the directions page. The two hash marks make the heading, the double asterisks make the bold, and the brackets make the link. That is the entire trick. If you can read that sample, you can read your own site’s content, because your whole site is files like this one.

Compare that with a page builder, where your text lives inside the tool’s database. You cannot open your own content in a normal program, and without the tool you cannot even find it as a file. The words are yours, but the tool holds them.

What AI assistants changed

Here is the honest version of the claim. AI coding assistants did not make everyone a programmer, and I would not tell you otherwise. What they did do is make it practical for a careful, non-technical person to make small, well-described changes to a text-based site.

Updating your hours. Changing a price. Adding an announcement to the front page. These are exactly the kind of small, clearly stated tasks assistants handle reliably. You describe the change in plain English, the assistant edits the text file, and you look at the result before it goes anywhere.

The plain text files are what make this possible. The assistant can read your pages as easily as you can. The same assistant cannot safely reach inside a page builder’s database and rearrange it on your behalf, which is why owners of those sites are still emailing their developer.

Why you cannot break it

Now the fear underneath all of this: what if I ruin the site?

On a site built the way I build them, you cannot, not permanently. The site lives in a repository, which is a folder with a complete memory. Every version of every file is kept, so any change can be undone entirely. The worst realistic outcome of an editing mistake is putting the site back to yesterday’s version, which takes one step, and the guide I hand over shows you that step.

Hold that against the page-builder status quo, where one bad plugin update can take the live site down with no earlier copy to return to. The setup that makes your site safe for you to edit is the same setup that protects it from everything else.

What I hand over

Every site I build ships with a written guide in plain English, specific to that site’s actual pages. Not generic documentation: it names your files, uses your content in its examples, and assumes you have never touched code. It covers how to edit a page, how to add a new one, how to publish a change, and how to undo anything.

You are free to ignore it. Some owners would rather hire someone for every change, and I am glad to be that someone, quoted by the task. The difference is that hiring help becomes a preference instead of a dependency. Either way, you hold the keys to your own website, which is how it should have been all along.