Let me start with a confession: I am not a developer. I can write basic HTML, I can make a page look decent with CSS, and I know roughly what a database is. That’s it.
Still, as of this week, I run six sites and small apps on my own domains. There’s a personal finance dashboard with a database behind a login. There’s a tool that collects charging sessions from a family’s wallbox and produces monthly receipts. There are two websites for local clubs, a personal landing page, and the blog you’re reading right now. All of them live on one Cloudflare account.
I didn’t write the code. AI coding agents did, mainly Claude Code and Codex. What I did was decide what I wanted, check what came back, and pick a hosting setup that someone like me can actually understand and keep running. This post is about that last part, because it matters more than people think.
The real problem isn’t writing code
If you’re a marketer playing with AI agents, you quickly notice that getting code written is no longer the hard part. You describe what you want, and a few minutes later something works on your laptop.
The hard part comes next. Where does it run? Who patches the server? What happens when it breaks at 11 pm? How do I stop the whole internet from seeing my finance data? Classic web hosting answers those questions with things I can’t do: SSH into servers, configure Nginx, renew certificates, update PHP, manage database backups.
What I needed was a setup where the agent can do the work and I can still understand what’s going on.
What I actually use
Everything follows the same simple pattern:
- Workers with static assets. Each site is a folder of plain HTML, CSS and a bit of JavaScript, plus a small script (a “Worker”) that runs on Cloudflare’s network. No server I have to maintain.
- D1 for the databases. It’s SQLite under the hood, which means the data is one file I could download and open myself if I wanted to.
- R2 for files, such as the photo uploads on a club site or the images on this blog.
- Cloudflare Access to put a login in front of anything private. My finance app is only reachable after an email code to my own address, and I didn’t have to build a login system to get that.
- DNS in the same place. The domains already sit at Cloudflare, so connecting a new subdomain to a Worker is one line in a config file.
And the most important bit: all of it is described in files inside the project. There’s a config file per project that says which database, which storage bucket and which domain it uses. Deploying means running one command. No clicking around in dashboards that nobody remembers a week later.
Why this fits a non-developer so well
One place, one bill, mostly free. My sites don’t get millions of visitors. The free tier covers almost everything, and if I ever outgrow it, the paid Workers plan starts at five dollars a month. I don’t have five hosting providers with five logins and five invoices.
Nothing to patch. There’s no operating system under my sites that I’m responsible for. That alone removes the scariest class of problems for someone like me.
Agents understand it. This is the part that surprised me. Because the whole setup is files (a config, a database schema, a folder of pages), an AI agent can read it, change it and deploy it. When I ask “add a page that shows last month’s charging sessions”, the agent knows where the database is, how it’s structured and how to ship the change. A hosting setup that lives in a web dashboard is invisible to the agent. A setup that lives in files is something the agent can work with.
Rollback is built in. Every deploy is a version. When something breaks, going back takes a single command. For two club websites I even left the old hosting running in parallel: the Worker simply sits in front of it. If I remove one route, the old site is live again. That’s the kind of safety net you want when you’re not sure you know what you’re doing.
Security I didn’t have to build. Putting Access in front of an app took one setup step. Building a secure login myself (or rather, trusting an agent to build one) would have been a much bigger risk.
What went wrong (so you don’t have to repeat it)
It isn’t magic. A few things bit me, and all of them are now written down in the projects so that neither I nor the next agent falls for them again:
- Two accounts, one mistake. I have a work Cloudflare account and a private one on the same laptop. An agent once created a database in the wrong account because the tool it used was connected to the work account. Now every private project has the private account ID written into its config, so a deploy to the wrong account simply fails.
- “Auto deploy” didn’t deploy. One site was supposed to redeploy on every push to GitHub. It silently stopped doing that. The fix wasn’t technical, it was a habit: after a change, check which version is live.
- A login that wasn’t a login. On one app, Cloudflare served the HTML files directly, before my login check ever ran. The data behind it was protected, but the page itself wasn’t. One setting (“run the Worker first”) fixed it. You only find this kind of thing by testing like an outsider.
- Error messages lie sometimes. Once the deploy tool claimed I wasn’t logged in. I was. A plugin had created a folder that confused it. An agent found that in minutes. I would have needed days.
The bigger point
For decades, “I’m not technical” meant “I need someone from IT or an agency for that”. With AI agents, that’s changing, but only if the platform underneath is simple enough that you can keep an overview. For me, that platform is Cloudflare. For you, it might be something else.
My rule of thumb: pick a platform where your whole setup can be written down in plain files. Then both you and your agents can read it. That’s what turns “the agent wrote me some code” into “I run this thing myself”.
This blog, by the way, is my latest experiment. It runs on EmDash, a new open-source CMS that runs on Cloudflare, and I’m testing it as a WordPress alternative. More on that once I’ve lived with it for a while.