The Complexity Floor
The simplest argument for keeping a personal site minimal is that you're the only one maintaining it. That sounds obvious until you watch someone spend a weekend debugging a CMS upgrade instead of writing.
There's a floor below which complexity stops generating support costs. Everything above that floor is a latent tax. The question isn't how much complexity you can handle right now -- it's how much you can handle at 11pm on a Tuesday when something breaks and you just want to post.
The consumer middle
The pattern appears outside publishing too. Smart home devices that need WiFi profiles and cloud sync to tell you your weight. CI pipelines that require their own monitoring to stay healthy. Frameworks that need plugins to manage their own upgrades. In each case, complexity was borrowed from larger systems without borrowing the discipline those systems run on. The result is a thing that generates maintenance work proportional to its ambition and inversely proportional to its engineering rigor.
Independent publishing hits this ceiling fast. A solo blogger doesn't have an ops team. There's no one to page at 3am. The support queue is you, and if the queue grows long enough, the site goes dark -- not from a decision, just from entropy.
The two exits from this trap are the ones Sumit Birla and Josh Sherman landed on independently: get sophisticated enough to be reliable, or get simple enough to not fail. Industrial-grade anything for a personal site is absurd. That leaves simple.
Simple isn't just fewer features. It's fewer moving parts that can degrade on their own schedule. Static files served from a CDN don't have a bad week. A flat Markdown directory doesn't have dependency conflicts. An RSS feed generated at build time doesn't go down when a third-party API changes its auth scheme.
The threshold question
The threshold isn't fixed. It's wherever your maintenance capacity runs out. For a developer with spare time and patience, it's higher. For someone who wants to write and not think about infrastructure, it's much lower. The mistake is assuming your present capacity is stable -- that the time you have now is the time you'll always have.
Building above your durable threshold is building for an imagined future self. That self has more time, more patience, more interest in infrastructure. She might exist. But the site has to survive until she shows up.
Every layer you add above the floor -- a commenting system, an email list, a search index, a preview deploy process -- has a carrying cost. Most of those costs are invisible when the layer is new and working. They show up when something breaks, when a service sunsets, when an API key rotates and nobody notices for two weeks. The cost isn't the setup. It's the maintenance surface area that accumulates silently.
The sites that stay alive longest aren't the ones with the best features. They're the ones where the owner never hit the point where keeping it running cost more than writing for it was worth. A site with twenty years of archive and no comments section isn't a failure of ambition. It's a system that stayed beneath its own operational ceiling.
Josh's note about CLAUDE.md sitting at /CLAUDE/index.html in the open is a minor example of the same thing. He knows the right fix is restructuring to a src/ subdirectory. He's not doing it today. That's not laziness -- that's a reasonable read of the cost. The site works. The fix introduces churn. The operational question wins over the architectural one.
That calculus is correct at small scale. The complexity floor isn't where you stop caring about good practice. It's where good practice means keeping the thing running over the thing being perfectly structured. Below the floor, you write. Above it, you maintain.