This Site Refuses to Go Down

Most personal websites are one bad deploy away from a blank page. A CMS hangs, an API key expires, a plugin updates itself into a fatal error, and the page that carries your name returns nothing. I refused to build that site. This journal runs on the system I am about to describe, so if you are reading this, the system is working.

The stack, on purpose

Next.js 15, React 19, TypeScript, deployed on Vercel. One repository, no backend of my own to babysit. That part is boring on purpose. The interesting decisions are in how the site reads its content.

The CMS is a luxury, not a dependency

My writing lives in a hosted Sanity studio. It is a real CMS: WYSIWYG editing, image and PDF uploads, revision history. But I set one rule on day one: the CMS is never allowed to take the site down. So the site reads Sanity through its public query API over plain HTTPS. No SDK. No client library pinned to a React version. No extra JavaScript shipped to your browser. One HTTP GET with a GROQ query, and that is the whole integration.

Every one of those fetches sits inside a three-second timeout and a 120-second cache window. Three seconds is forever for a CDN-backed read. If Sanity is slow, down, or having a bad day, the site does not wait around to find out.

The fallback ladder

Every content list on this site resolves in the same order:

• Sanity, if it answers in time.
• JSON files committed in the repository, if it does not.
• A designed empty state, if even those are missing.

The repository is the floor, and the site cannot fall below the floor. Committing content to git sounds old-fashioned next to a CMS. It is also the reason a total CMS outage changes nothing for a reader: the last committed content keeps serving, indefinitely, with no spinner and no 500.

A personal site should degrade like a good system: quietly, in order, never to zero.

Small details that compound

The sitemap regenerates every hour from the same fetchers the pages use, so a new post becomes crawlable without a redeploy. Article pages carry their own structured data, canonical URLs, and per-post Open Graph images. The whole site revalidates on a two-minute cadence, so publishing is a commit, not a deployment. None of this is glamorous. All of it is why the site is still standing on the days something upstream is not.

Why this matters more than it looks

Your name is infrastructure. When someone searches for you, the first result either loads or it does not, and that outcome was decided by engineering choices made months earlier. I build systems that should not be possible for one person. The least those systems can do is stay up.

This journal now runs on exactly this architecture. If the CMS ever reads this, no hard feelings. You are optional by design.