Every Sanity page builder has the same bug

Every Sanity marketing site ends up with a page builder. An array of sections, an insert menu, a render loop that maps block._type to a component. You've built it. I've built it. We've all built the same thing. And every one of them ships with the same bug. You add a new section. You wire it into the schema. You add a renderer. You add a component. You add the type. And then — because there are five places to touch and you're a human — you forget one. The section renders blank in production. Or it never shows up in the insert menu. Or it fetches no fields because you missed the GROQ projection, so it renders as nothing at all. No error. No red. Just a hole on the page where a section should be. The annoying part isn't the bug. It's that you'll hit it again on the next project, in exactly the same way, because you rewrote the whole thing from scratch — again. The section tax Here's what "add a section" actually costs in a typical Sanity + Next.js page builder: Schema — a new *Section object type, registered in your schema index. GROQ — a new conditional in the page-builder projection so the block's fields actually come down. Component — the React component that renders it. Renderer map — an entry mapping _type → component. Types — the block variant in whatever union your frontend renders. Miss #2 and the block arrives empty. Miss #4 and it silently skips. Miss #5 and TypeScript shrugs because your union is hand-maintained and now lies. Three different failure modes, all of them quiet, all of them "works on my machine until it doesn't." Now look at those five places and ask: which of them is actually unique to your site? The component is. It's welded to your design system — your spacing, your tokens, your brand. Nobody can reuse it and nobody should. The other four are plumbing . "Look up _type in a map, call the renderer, keep the map in sync with the schema and the query." That code is byte-for-byte the same idea on every project you've ever built. So why is it livi