A Four-Section Proposal Blueprint for Client Services

Nayan Kyada's detailed client proposal framework outlines specific scope, a 30-day delivery schedule, a 40/30/30 payment split, and a clear change-order policy. This structure protects both parties.

Many client proposals for development services lack clear boundaries for scope, timelines, or payment terms. Nayan Kyada, a Sanity CMS developer, detailed a four-section proposal framework that outlines a 30-day project timeline, a 40/30/30 payment split, and a $6,000 USD threshold for additional payment milestones. This structure aims to protect both the developer and the client from common project pitfalls, moving beyond a simple quote to a foundational contract.

What the Proposal Structure Actually Contains

Kyada's approach establishes a proposal not as a price list, but as a project contract in plain language. It comprises four non-negotiable sections: scope, milestones with deliverables, payment schedule, and change-order policy. This comprehensive structure ensures all parties understand the project's parameters and expectations upfront. A developer who omits any of these sections risks ambiguity and potential disputes.

Defining Project Scope with Exclusions

The scope section names every content type, page template, and integration. In one proposal from early 2026, Kyada listed 9 Sanity schema types (product, article, author, category, FAQ, navigation, settings, redirect, legal page), a Next.js App Router front-end, and Vercel deployment with preview URLs. Crucially, the scope explicitly stated exclusions: no Algolia or e-commerce API work unless a change order was signed. This boundary definition is often overlooked by clients but serves as the most important paragraph in the document, preventing scope creep before it starts.

Milestones Map to Deliverables and Dates

Kyada's proposal includes a table of five specific milestones, each tied to concrete deliverables and calendar days. The first milestone, Project Kick-off on Day 1, requires a live staging URL, a deployed schema skeleton, and Studio login credentials. This immediate staging URL is non-negotiable for Kyada, providing the client with a tangible asset to track progress. Subsequent milestones include Schema Complete by Day 8, Front-end Alpha by Day 18, QA and Revisions by Day 26, and Production Launch by Day 30. Each milestone provides a clear checkpoint for both progress and accountability.

Structured Payment for Predictable Cash Flow

For a typical 30-day Sanity project, Kyada uses a 40/30/30 payment split: 40% upon contract signing, 30% upon completion of Milestone 3 (front-end alpha), and the final 30% upon production launch. This distribution balances the client's risk with the developer's need for predictable cash flow. For projects exceeding $6,000 USD, Kyada introduces a fourth payment, adding a payment at Milestone 2. This creates more frequent checkpoints and allows either party to address concerns before significant work accumulates, mitigating risk for larger engagements.

Change Orders Require Signed Agreement

To manage scope creep, Kyada's proposals include a specific change-order clause. The language states: "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." This clause ensures that clients receive a predictable process rather than surprise invoices. It also provides the developer with a clear paper trail for any work beyond the initial agreement, protecting against uncompensated effort.

What We'd Change

While Kyada's proposal framework offers robust protection, its direct application requires adaptation. The 30-day project timeline, while efficient for a specific Sanity CMS build, is aggressive for projects involving extensive client feedback loops, complex integrations, or novel design work. Many projects, especially those with multiple stakeholders, require more buffer for review and revision cycles. Founders should adjust milestone durations based on project complexity and client-side availability, rather than adhering strictly to a 30-day default.

The explicit exclusion of Algolia or e-commerce API work highlights the importance of defining boundaries. However, the specific technologies (Sanity, Next.js, Vercel) are context-dependent. The principle of clear scope definition and exclusion lists is universally applicable, but the details must be tailored to the specific tech stack and project requirements. Founders working with different platforms would need to customize these technical specifications accordingly.

The change-order clause, while strong, leaves the [day rate] as a placeholder. For maximum clarity and to avoid future negotiation, this rate should be explicitly defined within the proposal itself. Leaving it open can introduce friction when a change order is required. Furthermore, while the framework is excellent for fixed-scope projects, it needs modification for ongoing retainer work, where the scope is inherently more fluid and requires different contractual mechanisms like monthly hour blocks or feature-based sprints.

Landing

A well-structured proposal is not a price list. It is a project contract in plain language. The detailed framework presented by Nayan Kyada transforms a mere quote into a comprehensive agreement. By clearly defining scope, deliverables, payment terms, and change-order procedures, founders can establish transparent expectations and minimize disputes. This proactive approach builds trust with clients and provides a solid foundation for project execution, ensuring both parties understand their commitments and protections from the outset.

Pull quote: “A well-structured proposal is not a price list. It is a project contract in plain language.”