Building the ONRS website: a technical postmortem

Why Notion as a CMS?

We needed a system that non-technical editors could use without training, that supported rich content (images, callouts, tables, embeds), and that didn't require us to build an admin interface from scratch.

Notion met all three criteria. The tradeoff was that we had to build a renderer that could faithfully translate Notion's block model into clean HTML.

The stack

javascript

Notion (CMS) → Notion API → Astro (SSG) → Cloudflare Pages (hosting)

Notion: Content authoring, editorial workflow (Draft → Published → Archived)
Astro: Static site generation with component-based rendering
Cloudflare Pages: Fast, free hosting with automatic deployments from Git
Notion API: Fetches pages and databases at build time

What worked

Editors love Notion — zero training requiredBuild times are fast (< 30 seconds for 50+ articles)Cloudflare's CDN handles traffic spikes without configurationBilingual content via separate database properties

What didn't

Notion's API rate limits slow down full rebuildsImage handling is fragile — Notion's signed URLs expireNo native preview — editors can't see the rendered site without deployingBlock type coverage is incomplete (buttons, synced blocks, some embeds)

Lessons learned

What we'd do differently

Image pipeline: Upload images to R2/S3 at build time instead of using Notion's signed URLs
Incremental builds: Use webhooks to rebuild only changed pages
Preview environment: A staging deployment triggered by a "Preview" status in Notion
Content validation: A pre-build check that flags missing required fields (slug, summary, hero image)

Alex

Why Notion as a CMS?

The stack

What worked

What didn't

Lessons learned

What we'd do differently