Running twenty sites solo

A friend came over last week and watched me close my laptop at 5pm. He said “wait, that’s it? You run twenty sites.” It sounded like an accusation.

I get asked this at least once a month. How do you maintain twenty sites by yourself? The honest answer is that I don’t, really. Most of them don’t need maintaining. Which is what I want to tell you about, because the part that makes that possible is a rule I wish someone had drilled into me five years ago.

The rule that made everything else possible

If a project needs me to check on it weekly, it’s a bad project.

That’s it. That’s the whole rule. Every time I find myself in a Monday routine of “let me go make sure X is still working” — whether it’s a dashboard I built, a content pipeline I wrote, a dependency I’m nervous about — the project is failing. Not slowly. Failing.

The options at that point are three, and only three: automate what I keep checking, rebuild the thing until it doesn’t need checking, or kill it.

Two years ago I had a site that scraped a gaming leaderboard and republished it with commentary. Decent traffic, a few hundred bucks a month. I was checking it every Monday because the source site kept changing their HTML. Every few weeks something would break and I’d spend an afternoon chasing it. I finally added up the hours and the revenue and realised I was earning $4 an hour on this thing when you count the babysitting. Killed it the next day. Haven’t missed it once.

The ones I didn’t kill — the twenty I still run — all pass this test. They sit there quietly. I can leave them alone for a month, and they’ll be fine a month later.

What “sits there quietly” actually means

Boring is the whole trick. Every new project I start now, I ask: can this be boring?

Static pages wherever possible. No user accounts unless the product literally cannot exist without them (turns out, usually it can). No cron jobs I can’t explain in one sentence. No third-party integrations that can fail silently. When a dependency upgrades, I want to know within seconds if the site broke, not three weeks later when someone emails.

The corollary is: I build almost nothing in isolation anymore. Every site I ship uses the same bones. Astro for the pages, Cloudflare for hosting and DNS, Markdown or a JSON file for content, Postgres if I need persistence. That’s it. Four pieces. If a new project doesn’t fit this stack, I’ll often just not build it, because the long-term cost of a bespoke stack is higher than the short-term win of the feature.

Standardising was the biggest single productivity change I’ve made as a solo operator. When every project has the same bones, the bones stop costing me cycles.

The monitoring I actually have

You would assume, running twenty sites, I’d have an elaborate observability setup. Grafana dashboards, alert channels, a PagerDuty rotation of one.

I don’t. I have UptimeRobot hitting the important URLs every five minutes, and that’s the whole monitoring stack. If something breaks badly enough to matter, it’ll show up in revenue or traffic within a day, and I’ll see it. If it’s too subtle to show up that way, it’s also too subtle to be worth waking up for.

Real engineers hate this. That’s fine. The ops practice that would be correct at a company of fifty people is comic overkill for a company of one. I’d rather spend the hours I’m not spending on dashboards on writing the next thing.

What actually eats my time

Maintenance doesn’t. The two things that eat my week are:

Deciding what to build next. This is harder than it sounds when you already have twenty things you could be pushing on. I wrote more about this in another post.

And then actually building it. Shipping the next project, or the next big feature for one of the flagship sites.

I probably spend 15% of a typical week keeping old stuff alive, 20% on the blog and the consulting, and the rest on whatever the next thing is. If that ratio tips the other way for more than a few weeks, one of the old projects has started failing the weekly-check rule, and I need to fix it or kill it. There’s no middle ground.

The takeaway, if you’re managing more than one thing

Apply the weekly-check test to every project you run. Be honest about which ones demand regular attention. Then fix them until they don’t, or let them go. You can run a portfolio ten times the size of mine if none of the individual items are loud, and you can run zero sites if even one of them is loud enough to take over your week.

Twenty quiet sites beat three loud ones, every time. The hard part is being willing to kill the loud ones when they stop being worth the noise.