A Sanity CMS development services proposal should tell you exactly what you're buying, when you'll see it, and what happens when scope shifts. Most proposals I see from developers — including ones I competed against early in my career — skip at least two of those three. Here is what a real one looks like, pulled from a proposal I sent to a mid-sized e-commerce brand in early 2026.

What the proposal structure actually contains

A well-structured proposal is not a price list. It is a project contract in plain language. Mine runs four sections: scope, milestones with deliverables, payment schedule, and change-order policy. Buyers should expect all four. If a developer sends you a single paragraph with a number at the bottom, that is not a proposal — it is a quote, and quotes do not protect either party.

Scope names every content type, every page template, every integration. My 2026 proposal listed: 9 Sanity schema types (product, article, author, category, FAQ, navigation, settings, redirect, legal page), one Next.js App Router front-end, Vercel deployment with preview URLs, and no Algolia or e-commerce API work unless a change order was signed. That last sentence is the boundary. Buyers often gloss over the exclusion list; it is actually the most important paragraph in the document.

Milestones map to real deliverables, not vague phases. Here is the milestone table from that proposal:

The staging URL on day one is non-negotiable for me. It costs almost nothing to spin up a Vercel preview deployment from a skeleton repo, and it gives the client a live URL they can bookmark, share with their team, and hold me accountable against. A developer who cannot give you a staging URL within 24 hours of kick-off either has no deployment workflow or has not started.

Payment schedule and what a fair split looks like

My standard split for a 30-day Sanity project: 40% on contract signing, 30% on milestone 3 (front-end alpha), 30% on production launch. Some developers ask for 50% upfront on smaller projects, which is reasonable. What is not reasonable is 100% upfront or 100% on completion — the first exposes you to a developer who disappears, the second exposes the developer to a client who stalls sign-off indefinitely.

For projects above ₹5 lakh or $6,000 USD, I split into four payments rather than three, adding a milestone 2 payment. This keeps cash flow predictable on both sides and creates natural checkpoints where either party can raise concerns before too much work has accumulated.

How scope creep is handled in writing

The change-order clause in my proposals reads something close to this:

Any work outside the scope defined in Section 1 — including new schema types, new page templates, third-party integrations, or design changes after milestone 3 — requires a signed change order before work begins. Change orders are priced at [day rate] and billed at the next milestone payment.

That clause protects both of us. Clients get a predictable process rather than surprise invoices. I get a paper trail rather than a verbal request that mutates over three Slack messages. The most common scope creep I see on Sanity projects: a client asks to add a blog after schema was already finalised, or they introduce a product configurator that requires a new document type mid-build. Neither is unreasonable — they just need to be priced and scheduled explicitly.

Red flags to watch for in a proposal you receive

If you are evaluating proposals from multiple developers, here is what to look for:

No staging URL commitment. If the proposal mentions a staging environment but gives no date, the developer has not thought through their deployment setup. Ask them directly: when will I receive a staging URL?

Milestones tied to hours, not deliverables. "Week 1: 20 hours of development" tells you nothing. Milestones should name something you can see — a URL, a document, a deployed schema.

Vague revision policy. "Revisions included" is not a policy. How many rounds? What counts as a revision versus a change order? My proposals specify two rounds of QA changes, each submitted as a single consolidated list.

No exclusion list. A proposal that does not say what is out of scope implicitly includes everything. That is how a ₹3 lakh project becomes a ₹6 lakh project.

Payment on client satisfaction. Final payment tied to subjective satisfaction — rather than a defined deliverable like production deployment — is a recipe for stalled projects. The deliverable should be objective: DNS pointing to the new site, redirects returning 301s, Lighthouse scores above a stated threshold.

What you should ask before signing

Three questions worth asking any developer before you accept a proposal: Who owns the Sanity project dataset if we part ways? (You should.) What is the handoff process — do you get a recorded walkthrough and written Studio guide? Is there a retainer option for post-launch support, and what is the response-time commitment?

Ownership of the dataset is particularly important with Sanity because all your content lives in Sanity's hosted infrastructure. The project ID and dataset should be registered under your organisation's Sanity account, not the developer's. This is a one-minute configuration decision that some developers skip for convenience. Do not let them.