Sanity Studio handoff: how your team edits the site without a developer

At handoff you receive a working Sanity Studio configured to your content, login accounts with the right permissions, and a publish flow where an edit goes live in seconds — no developer, no ticket, no deploy. This post covers what’s in the box and what a normal editing day looks like. For why Sanity suits non-technical teams in the first place, see Sanity for non-technical teams; here we focus on the delivery and the day-to-day workflow.

What you actually receive at handoff

A handoff is a deliverable, not a hope. When we wrap a new build, you get:

• A typed Studio, configured to your content. Every content type your site uses — service, blog post, page, team member — is a defined shape with labelled fields. You edit headlines, images, and prices in plain forms, not a freeform canvas.
• Login accounts with the right roles. Each person on your team gets their own account scoped to what they should be able to do (more on roles below).
• Live preview wired up. A draft renders on a real page so you see the change in context before anyone else does.
• A short written runbook. How to log in, where each content type lives, how to publish, and how to roll back — plus a 30-minute walkthrough recording.

Roles: who can change what

Sanity has role-based access, and we set it up so the right people have the right reach:

• Editors create, edit, and publish content — the day-to-day marketing work. They can’t change the schema, billing, or who has access.
• Administrators do everything editors do, plus manage team members, datasets, and project settings.
• Viewers (optional) can see drafts and preview but not publish — handy for a reviewer or a client stakeholder.

You can’t accidentally delete the site or break the layout from an editor account. The design lives in code; editors supply content within the fields we defined.

The publish flow: edit → preview → live in seconds

Here’s the loop your team runs every time:

1. Open the document — say, the homepage hero or a blog post — in Studio.
2. Edit the fields. Change the headline, swap the image, update a price. Validation runs as you type: a URL field rejects a phone number, a required field won’t let you publish empty.
3. Preview. Open the live preview to see the change rendered on the actual page, in context, before it ships.
4. Publish. Hit publish. The site rebuilds and the change is live in seconds. No deploy command, no developer in the loop.

Because Sanity keeps document history, you also get a safety net: every publish is versioned, so you can see what changed and restore a previous version if something looks wrong.

A realistic editing day

Say a price changes and a new case study lands. Your editor:

• Opens the Service document, updates the starting price field, previews the services page, and publishes. Because “service” is structured content, that price updates everywhere it appears — the homepage, the services index, the nav — from one edit.
• Creates a new Blog post document, fills in title, dek, body, and a hero image, previews it, and publishes. The post appears in the index, the RSS feed, and the sitemap automatically.
• Notices a typo on the About page, fixes the field, and publishes. Total time: under a minute.

None of that needed a developer, a ticket, or a release window. That’s the point of the handoff.

Where the care plan fits

Self-editing covers content. It does not cover structure — and that’s where a care plan comes in. Use it when you’d rather hand the work off, or when the change isn’t a content edit:

• New content types or fields — adding a “case study” type, or a new field to an existing one. That’s a schema change, which is code.
• New section layouts or design changes to how content renders.
• Dependency and security updates, performance checks, and the occasional “can you just do this for me.”
• A second pair of hands during a big launch.

Think of it as the difference between writing in the Studio (you, any time) and changing what the Studio can do (us, on the care plan). Plenty of teams self-edit happily for months and only reach for care when they want a new capability.

FAQ

Do we need a developer to publish a normal content change? No. Editing and publishing content — text, images, prices, new posts — is entirely self-serve from Studio. You only need a developer to change the structure (new content types or fields), which is what a care plan is for.

How long after I hit publish is the change live? Seconds. Publishing triggers a rebuild and the static site updates; visitors see the new version almost immediately. You can confirm it on the live URL right after.

Can someone on my team break the site by editing the wrong thing? Editors work inside defined fields, so they can’t alter the layout or delete the project. Validation blocks bad input before it publishes, and every publish is versioned — so a mistake is recoverable, not catastrophic.

What training comes with the handoff? A 30-minute live walkthrough, a recording of it, and a written runbook pinned inside Studio. Most teams are publishing confidently the same day.

What if we want changes we can’t make ourselves? That’s the care plan. Send the request and we handle schema changes, new sections, updates, and maintenance — so you self-edit the everyday content and hand off the structural work.

Getting there

A new build sets the Studio up from day one, and the handoff above is part of the deliverable. Want to understand the editing model before the handoff? Start with Sanity for non-technical teams. When you’d rather hand off the structural work, a care plan is waiting. See how an engagement runs.