# The Ultimate "Page Builder" Studio

![Japanese salaryman typing on a white computer with the large text "Stop Scaffolding. Start Shipping." on the blank screen. looking out to the view of 80s japan midday](https://cdn.sanity.io/images/cyu7k2r0/production/d7b6a45c5ca6bc89d3386e193cd2b9a82f99e1c3-1344x896.png)

> _SanityPress is a pre-configured Sanity Studio on Next.js, built for rapid and scalable website development. This is how the module system underneath it works, and why it makes the next client site faster to start and easier to grow._

Every client website starts the same way. A blank repo, a fresh Sanity project, and a familiar voice in the back of your head: _I've done this part before._

You need: The page-builder schema. The array of content blocks. The switch statement that maps each block to a React component. The live preview setup so editors can see what they're doing (a.k.a. WYSIWYG).

None of it is the website. All of it is the thing you build before the website, every single time, from memory, slightly differently than last time.

This is a post about making that part cost nothing. Not by skipping it, but by solving it once and never starting from zero again. That solution has two halves, and they map cleanly onto what _SanityPress_ promises: **a Studio that arrives pre-configured**, so the next site is rapid to start, and a module system that holds its shape as you add to it, so **the work stays scalable across every client you take on.**

## The part that shouldn't be your problem

A marketing site is a stack of sections. Hero, then unique value props, then testimonials for social trust, then som call-to-actions.

Editors want to reorder those sections, swap them, drop one in the middle without filing a ticket. That requirement is the same on every project.

The client's brand is different every time. The page-building machinery underneath it is not.

So the question worth asking isn't "_how do I build a page builder._" You know how. The question is "_why am I building it again._" The honest answer is usually that the last one lived in a client repo you've moved on from, and porting it felt like more work than rewriting it.

A module system fixes that by making the page-building layer a stable, named thing you carry forward, while leaving everything visual unstyled and open. You bring the architecture. The project brings the brand.

## What a module actually is

In SanityPress, a page is an array of modules. A module is three parts that always travel together:

1. **Sanity schema** that defines the editable fields.
2. **React component** that renders those fields on the frontend.
3. An entry in the **resolver** that maps the schema's type name to the component.

That's the whole contract. Once those three exist, the module is available to every page, reorderable in the Studio, and rendered automatically on the frontend. The shape of that relationship is the thing worth holding in your head:

A page holds an ordered, reorderable list of modules. Each module is identified by a type name (`hero`, `callout`, `card-list`) and contains its own fields and options: the editable content and the knobs that change how it behaves. The schema defines those fields, the component renders them, and the resolver matches the type name to the component so the right thing shows up on the page. Three parts, one type name tying them together.

This is what scalable looks like in practice. The leverage compounds because the contract never changes: your tenth module is the same amount of work as your first, and a module you wrote a year ago drops into a new project untouched. The page builder stops being something you build and becomes something you extend, one client at a time, without the foundation shifting under you.

![Diagram: a website is built of pages; pages are composed of modules; modules are componsed of fields and options.](https://cdn.sanity.io/images/cyu7k2r0/production/be3c552b200a1e64f58f581cc95c58dd8c57e0ea-1536x1024.png)

## A Studio that arrives configured for the web

The schema and component story is half of it. The other half is who sits in the CMS.

Out of the box, Sanity is deliberately unopinionated: a content backend that will model anything you ask it to. That flexibility is the point, but for a website it means you're the one who has to teach the Studio that it's building a website. SanityPress does that teaching up front. This is the pre-configured part: the Studio arrives organized around pages, not around abstract documents.

Concretely, the editor opens a page and sees its modules as a single reorderable list. They drag the testimonial above the feature grid. They add a callout in the middle. They reorder, they delete, they preview, and at no point do they touch a field that wasn't meant for them. The structure mirrors how a website team actually thinks: pages, posts, site-wide settings, navigation. With the Presentation tool wired in, that module list maps directly to the rendered page, so editing feels like editing the site rather than editing a database that happens to feed one.

This is the difference between a CMS you bend into a website tool and one that shows up already bent. You stop explaining your architecture to clients. The Studio explains it for you.

![SanityPress Studio screenshot of the Page document editor](https://cdn.sanity.io/images/cyu7k2r0/production/28f9d8d63dc6d953158f37e9af232c0284ae3f49-3196x2348.png)

_[Explore more screenshots](/docs/sanity-studio-screenshots)_

## What changes on day one

Here's the part that's hard to feel until you've lived it.

The next project doesn't start at zero. You clone one foundation you already trust. The page builder is there, the Studio is pre-configured, and live previews work out-of-the-box. Day one isn't plumbing. Day one is building the hero section your clients will actually see, the modules unique to their brand, and a website that's truly theirs.

That's the rapid part, and it's real. The scalable part is what happens after: re-skinning existing modules, adding new options, or even creating completely new modules. Requests from the client or marketing teams handled at ease—whether in the code or directly in the Studio (no-code!). Speed at the start, leverage over time. Both come from the same place: infrastructure SanityPress has solved for you, so every hour after lands on actually designing and building the website.

That's the shift, and it's quiet. No more rebuilding the wheel from memory. No more porting the page builder out of an old repo. **The setup is done, and you get to build.**

> **Ready to build?**
> Your next client site begins where the boring part ends.
> [Get started with SanityPress](/getting-started)