Short version: let the agent build it, then think hard about who runs the server afterwards. The building part has genuinely got good. Describe a business in a paragraph and you get a clean, fast marketing site, which used to be a week of somebody's time and a few hundred pounds. What has not changed is that a server is a thing somebody has to keep patched, every month, forever. Agents do not do that part yet.
Founder of Simplepages here, so obvious bias. Though it cuts both ways, because for a lot of people the right answer is a static host that is not us, and I will get to that.
What the agents are genuinely good at
Ask Claude or any decent coding agent for a plumbing business site and you get something real: sensible structure, copy that is not embarrassing, a contact form, fast on a phone. Ask it to move the booking button and it moves the booking button. Most tools in this category can do that now, ours included, and if you tried two years ago and gave up it is worth another look.
The job that starts once it is live
If the agent set you up on your own virtual server, you now own a Linux machine on the internet. That machine runs an operating system, a web server, probably a language runtime, and a handful of libraries. Every one of those is a thing that gets security advisories, and the advisories do not care that you run a plumbing business.
| The job | On your own server | On a managed platform |
|---|---|---|
| Patching the operating system | You, on a schedule you set | Platform, usually invisibly |
| Upgrading the language runtime | You, including the breaking changes | Platform |
| Restarting after a patch so it takes effect | You, and it is easy to forget | Platform |
| Noticing a disclosure in the first place | You, by following security news | Platform |
| Rotating credentials after a provider is breached | You, for every key you stored | Shared, and they should tell you |
Nobody raises this up front because it is boring and it happens later, long after whoever built the site has been paid and moved on.
What that maintenance actually looks like
Writing about this usually stops at "keep your server updated", which makes it sound like a monthly checkbox. Having done the work, three things make it harder than that, and none of them are obvious until you hit them.
- Running an older OS release can mean there is no patch at all. Linux distributions stop publishing security updates for a release after a fixed window, and the shorter non-LTS releases run out quickly. Once that happens the usual update command has nothing to give you. The fix becomes a full operating system upgrade or moving the software into a container, which is a weekend, not a checkbox. The failure is quiet: the update command keeps succeeding and keeps changing nothing.
- Installing a patch is not the same as applying it. Long-running processes load code once and hold it. Upgrade the package and the running copy carries on serving visitors with the old code until you restart it, so the files on disk can be current while the process answering your customers is still the vulnerable one. Nothing warns you about this.
- Container images come with defaults, not with your setup. Moving to an official image is often the cleanest way to get a supported runtime, though it does not retire the machine underneath: the host operating system still needs patching, and the image itself needs rebuilding when its own base is updated. Those images also ship deliberately bare. A common one: error display defaults to on, because the image does not assume it is in production. A broken include then prints your server's file paths into the page, in front of customers, until somebody notices.
And you have to be watching
All of that assumes you know there is something to fix. The clock starts when a vulnerability is published, not when you happen to read about it, and the gap between those two is the part you control. It is getting harder, too: the researchers at Wiz who found the critical PHP flaws disclosed this October used AI to find them, and say so in their write-up. Finding bugs is speeding up faster than anyone's patching is.
The other thing you now own
Running your own stack also means holding your own secrets. Whatever the agent wired up is sitting in environment variables on a machine you are now responsible for, and it is usually more than people expect:
- Database credentials, which hand over everything in the database to whoever has them.
- Payment provider keys, where it is worth knowing whether yours are the live ones or the test ones, because people mix them up.
- Email sending keys. These are the ones people forget, and they are the ones worth stealing, because mail sent with them passes your domain's authentication checks. Someone phishing your customers from your own domain is a worse afternoon than a defaced homepage.
That is not hypothetical. Railway, a hosting platform plenty of developers use, disclosed in October that an intruder may have reached customer environment variables and decrypted some of them, and told every customer to rotate every key they had stored there.
I am not pointing at Railway as the cautionary tale. They found it, said so publicly, and told customers exactly what to do, which is the behaviour you want and more than some larger companies manage. The point is that this is a category of work you inherit the moment you run your own infrastructure. Somebody has to know which keys exist and where they are, before the morning they need rotating.
When running it yourself is the right call
Plenty of times, and I would rather say so than pretend otherwise. Self-hosting is the better answer when:
- You or someone on your team already does this. If patching a server is a Tuesday for you, none of the above is a cost, and you get control that no platform will give you.
- The site does something genuinely custom. Once there is a real application behind it, a background job queue, an integration nobody offers, you will outgrow a managed builder and the tradeoff flips.
- You have a hard requirement about where data lives, or a client who does. Sometimes the answer is just "on this machine, in this country", and that settles it.
What I would avoid is drifting into it. Self-hosting because the agent happened to set you up that way, without anyone deciding to own the server, is the version that goes wrong. Six months later the person who built it has moved on and nobody knows which version of anything is running.
The actual decision
If your site is pages, pictures and a contact form, which covers most small businesses, there is nothing on that server worth owning. Static hosting is the category to look at, and there are several good ones. A folder of HTML files on a static host has no runtime to patch, which is the whole argument. You can export a Simplepages site as plain HTML and put it on any of them, or use our builder and let us keep the lights on. Either way the question worth answering before you start is the dull one: in a year, when something needs patching at an inconvenient time, whose job is it?
If you are weighing this up for a real business and want to talk it through, I am happy to. Good luck with the build either way.