{
  "id": 9640302,
  "title": "What shipping Sanity projects taught us about content models that survive redesigns",
  "url": "https://urgent.news/2026/09/24/what-shipping-sanity-projects-taught-us-about-content-models-that",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-24T22:18:01.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/madebymonogram/what-shipping-sanity-projects-taught-us-about-content-models-that-survive-redesigns-2j83"
  },
  "original_language": "en",
  "account": "The most crucial technical decision across multiple Sanity projects was defining content before crafting page designs. This schema determined content filtering, cross-linking, migration, preview, and rendering capabilities. The content model, not URLs, held the meaning and relationships. Modeling stable entities as documents rather than page-specific strings allowed for flexible filtering, cross-linking, and resurfacing without additional manually maintained fields.\n\nEditors received control through a fixed set of design system blocks, while the application managed spacing, color, and responsive behavior. On modular sites like M8, editors could reorder and recombine sections while preserving the exposed grid and visual system. Migrations required careful planning, starting with a legacy archive audit to decide what would carry over, be rewritten, or retired. The target content model then reflected these decisions before content relocation.\n\nQuery complexity exposed modeling problems if rendering one card needed multiple nested joins. The schema should own the data relationships, not the query. Treatment of Portable Text as structured rich text, not stored HTML, allowed consistent rendering across web pages, feeds, and machines. GROQ queries generated TypeScript types through Sanity Typegen, keeping content model, query result, and application code relationships visible.\n\nThe editor workflow should resemble a regular application, with customized Sanity Studio serving as a frontend application for specific user groups. Components, previews, and validation needed equal attention to the public interface. Integrations, like Hy-Vee KidsFit, turned editorial tasks into consistent content shapes, reducing manual metadata transfer. Collaborative editing, live previews, and on-demand revalidation completed the feedback loop, ensuring creators could see how changes would appear before publication. While the architecture separated publishing from deployment, maintenance remained necessary, requiring teams to manage dependencies, upgrades, custom components, and release surfaces.",
  "summary": "Across our Sanity projects, the most reusable technical decision was not a clever GROQ query. It was defining the content before defining the pages. For Kasada, Orb, Contextual AI, Zenity, Hy-Vee, Newfront, and our own M8 site, the schema determined whether content could be filtered, cross-linked, migrated, previewed, and rendered beyond one page template. The patterns below come from our…",
  "key_points": [
    "Define content before designing pages for stable modeling",
    "Editors control through design system blocks, not page-specific strings",
    "Portable Text as structured rich text for consistent rendering"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}