The site you’re reading runs on a stack you could explain in one breath: Astro for the static pages, Cloudflare Pages for hosting, Resend for the waitlist. No CMS, no database, no framework wars. Three moving parts.
What’s actually running
- Astro generates the HTML at build time. No JS by default, components only where they help, content collections for this journal you’re reading right now.
- Cloudflare Pages serves the static output, runs the one Pages Function we have (
/api/subscribe) on the edge, and handles the SSL. - Resend stores the waitlist contacts. The Pages Function takes an email, validates it, and writes it to the audience.
That’s the whole thing. The total dependency footprint is small enough that I can read every line of config in five minutes.
Why this stack and not the obvious one
The obvious choice for a content site in 2026 is some flavor of Next.js on Vercel with a database for waitlist. It’s good. It’s not what we needed.
If a stack adds capability, it has to earn its keep on every deploy.
We don’t need server-side rendering. We don’t need a database — Resend already is one for our purposes. We don’t need API routes beyond a single POST. Every dependency we don’t add is a deploy that doesn’t break later.
What we’d add later, if
- A real CMS, when there are more than ~20 journal entries and editing Markdown by hand stops feeling fast.
- A search index, when there’s enough content to need one.
- A staging environment, when there are people on the team who can break production.
Until then: small, sharp, slow to grow. Slow is fine. Sloppy isn’t.