A block-based CMS is the right shape even when the only editor is you
Four client CMSes and one portfolio later: uniform blocks with dumb fields beat clever schemas every time someone (including future-you) has to actually edit content.
I've now built content systems for a hotel, a nonprofit, a fashion storefront, a geospatial consultancy, and my own portfolio. The versions that survived contact with real editors share one property: content is an ordered list of typed blocks with a single uniform field shape, and the renderer decides what each type means.
The tempting alternative — a discriminated union where each block type has exactly its own fields — produces better TypeScript and worse software. Every new block type touches the schema, the editor, the store migrations, and the renderer. With a uniform shape, a new type is a renderer case and an editor label map; the store never changes.
Unused fields sitting empty on every block feel wasteful until you notice what they buy: the editor is one generic component, JSON round-trips through any storage without adapters, and half-written content never fails validation while someone is mid-edit.
The same argument holds for the hybrid storage layout — flexible JSON blobs for page chrome (nav, theme, hero copy) alongside real relational rows for things that need querying (bookings, leads, inventory). The mistake is picking one religion; the win is knowing which data is which.
Where blocks genuinely struggle: cross-block constraints. 'The stats block must match the hero numbers' is invisible to a per-block editor. So far the honest answer is: don't encode it, let the human read the page.