Maintaining a Website Without an Agency

A new service joins the portfolio. A price changes. A team photo needs updating. Three situations that lead to the same question on many business websites: can I do this myself, or do I have to call someone again?

With a classic WordPress site, the honest answer is often: better call. Not because the change is difficult, but because you are never quite sure what you are touching and what stops working afterwards.

That is not a technical problem. It is an architecture problem.

How the dependency builds up

It starts harmlessly. The website is built by someone who knows what they are doing. Plugin A for SEO, plugin B for security, plugin C for the contact form. Everything runs. Everyone is happy.

Then comes the first update. The owner looks at the notifications, feels unsure, and calls the service provider. They do the update. The next time too. And the time after that. At some point it becomes routine: the service provider does the updates, the texts too, since they are already in there, and new pages anyway, because they know the structure.

This is how a dependency grows that nobody consciously planned. The service provider knows the site, the owner barely knows it anymore. Every little thing gets outsourced because it “goes faster if they do it.” Faster for whom?

Over the years it adds up - not only financially, as I described elsewhere, but also as a quiet feeling of not really owning your own website.

What independent maintenance means in practice

In the architecture I use for migrations, all content lives as plain text files in the project folder. A new page is a new file. A new blog article is a new file. Texts, headings, paragraphs - all in a format that opens in any text editor.

The format is called Markdown. It is not a programming language. It is structured text - readable, editable, without a dashboard, without a login, without the risk of accidentally breaking something.

Changing a price means changing a number in a text file. Publishing a new blog article means creating a new file. The entire site code lives in a versioned repository - every change is saved, every earlier state can be restored. If you change something and do not like it, you simply step back. This safety net changes how relaxed you are with your own site.

What AI changes here

This is where it gets interesting - and it is an area that is developing very quickly right now.

If you maintain content in plain text files, you can bring AI directly into the workflow. A new blog article starts with a short prompt: topic, tone, length. A few sentences as instructions, and the draft is there in seconds. Revise, finalize, publish. No more writer’s block.

It also works by voice. If you prefer dictating to typing, you can tell an AI assistant the changes. New opening hours, an updated service text, an announcement for an event - spoken instead of typed, fully prepared.

And it goes further. So-called agentic AI - AI systems that carry out several steps in sequence on their own - can already fully automate content tasks today: regularly publish an article, update page content according to change instructions, submit drafts for approval. These are not visions of the future. They are tools that exist today and that, with the right architecture, can be used directly.

In the coaching session I show what of this is sensible and directly usable today - and what is still a gimmick.

Why I built the onboarding into every package

I have built processes for over 20 years and seen what regularly fails. The most common pattern: a system works well, but the people who are supposed to use it do not understand it well enough to touch it safely. So they leave it alone. It becomes a black box that nobody wants to touch anymore.

The same happens with websites. The technical quality is irrelevant if, after the migration, the owner is exactly where they were before: dependent, unsure, waiting. That is why a coaching session is part of every migration. Not as a nice extra, but as the core of the offer.

What still needs a developer

Honesty is part of it: not everything is doable on your own after a migration. Structural changes, new page types or more complex features still need someone with a technical background.

But that rarely affects the day to day. Updating texts, adjusting prices, publishing new content, swapping images, writing blog articles - after the migration that lies entirely in your own hands. And with AI support it goes faster than ever.

The balance reverses. Instead of being dependent on every little thing, there is a clear dividing line: what owners do themselves, and what is really developer work. And the second part becomes much smaller.

What this means concretely

A website that truly belongs to you is not one you merely pay for. It is one you understand, can change, and work with - without waiting for a phone call.

If you want to check this for your own site, you will find all the details on the AI website migration services page.

Further reading

• Markdown basics: structuring content without programming knowledge

About the author

Jochen Stier brings over 20 years of experience from IT service management and process optimization. He knows how quickly systems grow and how hard it becomes to get them back under control. With website migration he follows the same principle: fewer dependencies, more control. After the migration, owners can maintain their site independently - without an agency, without plugin chaos.