Serverless Is A Content Strategy

A portfolio does not need a database because it has content, and it does not need a server because it has a form. Those two assumptions, made by default, are how a personal site quietly becomes a second job.

The claim in this article’s title is that the serverless decision is not primarily a technical one. For a site whose purpose is publishing, the infrastructure determines how often you write, how much of your attention goes to maintenance, and how safely you can add the few dynamic features you genuinely need. Choose the architecture and you have chosen the content strategy.

What maintenance actually costs

Every running component bills you twice. The first bill arrives in currency, and for a personal site it is usually small. The second bill arrives in attention, and it is the one that matters. A server needs patching. A database needs backups, version upgrades, and an answer for the day its disk fills. A CMS needs plugin updates, and each update is a small decision you must be present for.

None of those tasks is difficult. The damage is quieter: every hour spent on operations is an hour not spent writing, and every open maintenance question makes the site a slightly less inviting place to work. A publishing platform that costs attention eventually stops being published to. I have seen this cycle in personal projects and in enterprise content systems alike, and the mechanism is the same at both scales.

What build-time rendering changes

Most of what a content site does is known before any visitor arrives. When pages are generated at build time and served as static files, the publishing workflow inherits the properties of a software workflow, and those properties turn out to be exactly what a writer needs.

Content becomes source-controlled, so every article has a history and nothing is ever lost to a CMS migration. Content becomes reviewable, so a draft can sit in a pull request and be read the way readers will read it. Content becomes portable, so the day you replace the framework, the writing moves with you as plain files. A schema validates every article’s metadata at build time, which means a malformed entry fails the build instead of shipping broken.

The cost model changes in the same motion. Static files served from a CDN cost close to nothing at personal-site traffic, and a cost that rounds to zero removes a subtle pressure: the site never has to justify its bill, so it never becomes a candidate for decommissioning during a busy season.

The dynamic layer should stay narrow

A static site still needs a small number of things a file cannot do. The discipline is in keeping that list honest. On this site, the list has one entry: contact intake.

The contact form posts to an API Gateway endpoint backed by a single Lambda function, which validates the submission, verifies a Cloudflare Turnstile token, and forwards the message through SES. The function runs only when someone submits the form, is billed only for those invocations, and stores nothing. There are no long-lived credentials in application code and no server listening for traffic that mostly never comes.

Each dynamic feature you decline to add is a security review you do not owe, a failure mode you do not monitor, and a cost you do not track. Before any addition, the question worth asking is the same one I put in front of enterprise clients considering an AI deployment: is there a simpler mechanism that meets the actual requirement? A newsletter can be a hosted service. Comments can be a link to a public thread. Analytics can be a CDN report. The requirement is usually real; the server is usually optional.

The publishing consequences

Assembled this way, the site produces a specific writing experience, and the experience is the point.

Publishing an article is a git push. There is no admin panel to log into and no editor state to trust; the same review habits that protect code protect the writing. Nothing about the site demands weekly attention, so the time between articles is spent writing rather than operating. And because the delivery layer is a CDN in front of files, a traffic spike is a caching event rather than an incident.

The pattern holds beyond personal sites. A small business publishing case studies, documentation, or a knowledge base fits the same shape: content known at build time, one or two narrow dynamic paths, and operational cost measured in dollars rather than in staff. The architecture is the same one I describe in The Stack Behind This Site, and the principle behind it, building the simplest system that meets the actual requirement, is the same one that anchors the Intelligent Business framework at enterprise scale.

Decide what you want the publishing to feel like, and let that decision choose the infrastructure. For most content, the answer is files, a build, and one narrow path for the things a file cannot do.