How to evaluate a Sanity CMS development services proposal before you sign

A Sanity CMS development services proposal lands in your inbox as a PDF or Notion doc. It might look thorough, but the details that actually protect you — scope limits, staging access, payment triggers — are often buried or missing entirely. This post walks through what those details should look like, drawn from a proposal I sent to a mid-size e-commerce brand earlier this year.

What a Sanity CMS development services proposal actually covers

A proposal worth signing has five parts: scope definition, milestone plan, payment schedule, staging promise, and a change-order policy. If any of those are vague or absent, you are carrying risk the developer should own.

Here is the milestone structure from the proposal I referenced:

| Milestone | Deliverable | Payment trigger | Target date | |-----------|-------------|-----------------|-------------| | Kickoff | Signed contract, repo created, Sanity project provisioned | 30% upfront invoice | Day 1 | | Schema draft | All document types defined, content model doc shared | Client review sign-off | Week 2 | | Staging live | Full site running on staging URL, editor can log in | 30% progress invoice | Week 4 | | Content QA | Client populates real content, punch-list collected | Client sign-off on QA doc | Week 6 | | Production launch | DNS switched, redirects verified, Core Web Vitals baseline | 40% final invoice | Week 8 |

Every row has a concrete deliverable, a named trigger for payment, and a target date. There is no row that says "development complete" without explaining what complete means.

The staging URL on day one — why this matters

One promise I put in every proposal is a staging URL within 24 hours of contract signing. Not a design mockup, not a Figma link — an actual URL where someone on your team can open a browser and see a running Next.js site connected to a real Sanity project.

This sounds like a small thing. It is not. It establishes that the developer has wired up the stack before, that the repo is real, and that you can verify progress at any point without scheduling a call. If a proposal does not name a staging domain and does not commit to a timeline for it, ask why.

For reference, the staging environment in that proposal ran on Vercel preview deployments, with a fixed subdomain (staging.clientbrand.com) set up via Vercel's custom domain on the preview branch. The Sanity Studio was deployed alongside it at staging.clientbrand.com/studio. On day one the client's marketing director could log into the Studio, create a test document, and see it rendered on the frontend — even though the site was empty. That single capability killed about five rounds of "how is it going?" emails.

Scope guardrails: what a good change-order policy looks like

Scope creep on a CMS build is predictable. Somebody sees the Studio and wants a new content type. A third-party integration appears that was not in the original brief. A legal team asks for a cookie consent layer three days before launch.

A good proposal names these situations explicitly and sets a handling process. The policy I use reads roughly like this:

• Any work not listed in the deliverables table is out of scope.
• Out-of-scope requests are estimated within 48 hours and presented as a separate line item.
• The client approves or declines in writing before work begins.
• Timeline extensions caused by out-of-scope additions are added to the project calendar and reflected in a revised milestone table.

What this does not say is "we will accommodate reasonable requests at no extra charge." That phrase is a trap. It sounds flexible and client-friendly, and it is the sentence that causes most freelance project disputes. If you see it in a proposal, ask for a definition of "reasonable."

Red flags to look for in a proposal

These are patterns I have seen in competing proposals clients have shared with me when asking for a second opinion:

Lump-sum deliverable with no milestones. "Build a Sanity CMS site: $12,000" with no breakdown means you have no payment leverage and no checkpoints. If the project stalls at week six, you have already paid most of it.

Hourly rate with no cap. Hourly billing on a fixed-scope CMS build transfers all estimation risk to you. A capable developer should be able to scope a standard content site to a fixed or capped price.

No mention of content migration. If your current site has hundreds of pages, ask specifically whether migrating existing content is included. It usually is not, and it is usually the most time-consuming part of the project.

Staging "available upon request." This means the developer does not have a repeatable deployment workflow. Staging should be automatic and always-on, not something you have to ask for.

Handoff described as "training available." Training your team on how to use the Studio they paid to have built should be included, not an upsell. Ask for a specific handoff session and ask whether documentation is part of the deliverable.

What to ask before you sign

Three questions cut through most proposal ambiguity:

1. Which items in this proposal have you delivered on a previous project, and can I see a reference or case study?
2. If the project runs two weeks over your estimate, what happens to the price?
3. Who owns the Sanity project and the Vercel account — me or you — and when is that transfer documented?

The third question matters more than most buyers realise. A developer who provisions a Sanity project under their own account and a Vercel team under their own billing creates a dependency that survives the engagement. You want those accounts in your name from day one, with the developer added as a collaborator — not the other way around.

A proposal that answers these questions clearly before you ask them is a good sign. One that requires three follow-up emails to pin down the answers is telling you something about how the project will be managed.