Working with Turbo Start Sanity

An enterprise-grade, open-source Next.js and Sanity starter built to scale to tens of thousands of pages while keeping editing genuinely pleasant.

Turbo Start Sanity is our open-source starter for teams who want a Next.js and Sanity stack that scales to tens of thousands of pages without turning the editorial experience into a chore. It is opinionated on purpose: the decisions that usually eat the first two weeks of a project are already made.

Getting started

One command scaffolds the whole thing:

Not bad for an extra "p" at the start of the command you were about to run anyway.

Why pnpm and a monorepo

The repo is a pnpm-driven Turborepo. The apps live under apps/ — web for the Next.js frontend and studio for Sanity Studio — and shared code lives under packages/: a validated env package, a shared Sanity client and queries, the page-builder blocks, a UI kit and a logger.

pnpm's content-addressed store means dependencies are linked, not copied, so installs are fast and disk usage stays sane across packages. The monorepo boundary keeps concerns separate while letting the frontend and the Studio share types and block definitions instead of duplicating them.

Live content, not stale rebuilds

The frontend fetches through Sanity's Live Content API, so published edits show up without a full rebuild. Combined with the Presentation tool and visual editing, editors click an element on the page and land on the exact field in the Studio.

Page-builder blocks, built with AI

The core content model is a page-builder: an array of typed blocks. Each block is a self-contained folder with its schema, its GROQ projection and a headless React component sitting together. Because the pattern is so regular, it is a great fit for AI-assisted work — hand an assistant one existing block as a reference and it can scaffold the next one, wiring up the schema, the query fragment and the component in the right places. Design tools like v0 slot in for the visual layer.

Fallbacks everywhere

The SEO model leans on fallback fields: seoTitle falls back to title, ogTitle falls back to seoTitle, and so on. Editors fill in what they care about and the system fills the rest, so nothing ships with an empty <title>.

Conventions worth knowing

  • Files are kebab-case: feature-cards-icon.ts, blog-card.tsx. Components are .tsx, utilities are .ts.
  • After any schema change, regenerate types before you rely on them.
  • Linting and formatting run through Biome, not ESLint and Prettier.

Break something? Good

It is open source. If you hit a rough edge, a pull request is the fastest way to make the next person's start smoother. Go build something.