₹2L Build Deposit 2026: My 3-Stage Contract Rules

Quick Answer: A ₹2L build should be split into three milestones: 40% on signed scope, 40% on staging acceptance, and 20% on production handover. In 2026 I use this structure on every custom build in Junagadh because it keeps cash flow positive, gives the client a real exit at each gate, and leaves no single invoice large enough to become a hostage situation.

Key Takeaways

• 40/40/20 beats 50/50: a 50% deposit sounds safer, but it concentrates risk in one acceptance event. Three stages spread the risk across the build.
• Tie money to artifacts: each invoice must point to a document the client already signed, not a calendar date.
• Keep a 20% tail: the final 20% pays for handover, runbook, and the 30-day review. It is the only leverage you have after launch.
• Pause, do not chase: if a stage is not accepted, work stops and the next invoice does not start. The contract says this before the first rupee moves.

Why a ₹2L Build Needs a Deposit, Not a Promise

A ₹2L custom build is small enough that a client can fund it from operating cash, and large enough that a ghosted invoice hurts. In 2025 I lost ₹62,000 on two projects where I invoiced 50% at the end. Both clients went quiet after the demo, and both had a new priority the following month.

The fix was not a tougher personality. It was a contract that made the payment schedule follow the delivery schedule. A deposit is not a sign of distrust. It is the price of reserving a slot in a small studio where four people cannot absorb a missing month.

Here is the cash-flow difference on a ₹2L build:

The 40/40/20 structure collects 80% before the final handover. That is enough to cover the team's time if the client disappears, and it still leaves a 20% tail that keeps the relationship accountable after launch.

The Three Stages and What Each One Unlocks

Every stage has a deliverable, a gate, and an invoice. The gate is a signed acceptance, not a verbal yes.

The percentages can move for larger builds. On a ₹6L project I use 30/40/30 because the staging build carries more risk. On a ₹55K website I use 50/50 because there is not enough scope for a third gate. The rule is to keep at least three gates on anything above ₹1L.

Stage 1: Scope Lock

The first invoice is the easiest to defend because it pays for the work that prevents the project from failing: intake, scope, and architecture. The client gets a document they can hand to another vendor if they decide not to continue. That sounds like a risk, but it builds trust and it filters clients who want a free discovery call disguised as a project.

Stage 2: Staging Acceptance

The second invoice fires when a staging build passes the acceptance checklist. The checklist is written in stage one and attached to the contract. The client can click through the same tests QA ran. If a test fails, the stage stays open and the invoice waits.

This is the stage where scope creep tries to enter. The answer is always the same: a new row in the scope ledger with a price and a revised date. If the client agrees, the invoice moves by the change order amount. If not, the feature waits for phase two.

Stage 3: Production Handover

The final 20% is not a tip. It pays for the deploy, the runbook, the key rotation walkthrough, and the 30-day review. I do not hand over production credentials until this invoice clears. That is not hostility; it is the only remaining leverage after the build is live.

The Contract Clauses That Do the Work

The contract does not need to be forty pages. It needs four clauses that are specific enough to survive a disagreement.

1. MILESTONE PAYMENTS
   40% on signed scope, 40% on staging acceptance, 20% on production handover.
   Each invoice references the signed artifact that unlocks it. No invoice is
   due before its artifact is signed.

2. ACCEPTANCE WINDOW
   The client has 5 business days to accept or reject a stage in writing.
   Silence after 5 business days is deemed acceptance for invoicing, but not
   for go-live. A rejected stage lists the failed test IDs from the checklist.

3. PAUSE AND RESUMPTION
   If an invoice is unpaid for 7 business days, work pauses. The delivery
   calendar restarts when payment clears. Paused days are added to the launch
   date and do not count as a delay by the studio.

4. HANDOVER
   Repository access, environment variables, and the runbook transfer on the
   final invoice. Until then, the studio retains administrative access.

The acceptance window clause is the one clients push back on. I explain it with a simple example: if the staging build passes the agreed tests and nobody replies for a week, the invoice should not be stuck forever. The clause is symmetric because the studio also has five days to fix a rejected test.

I am not a lawyer, and neither is most of my client base. For builds above ₹5L I ask a local Junagadh advocate to review the template once. The fee is ₹8,000–₹15,000 and it has paid for itself in avoided arguments.

How the Money Flows

flowchart TD
    A[Discovery call] --> B[Scope + architecture]
    B --> C{Scope signed?}
    C -- No --> B
    C -- Yes --> D[Invoice 1: 40%]
    D --> E{Paid?}
    E -- No --> P[Pause]
    E -- Yes --> F[Build]
    F --> G[Staging + QA evidence]
    G --> H{Acceptance tests pass?}
    H -- No --> F
    H -- Yes --> I[Invoice 2: 40%]
    I --> J{Paid?}
    J -- No --> P
    J -- Yes --> K[Production deploy]
    K --> L[Runbook + handover]
    L --> M[Invoice 3: 20%]
    M --> N{Paid?}
    N -- No --> P
    N -- Yes --> O[30-day review + case study]

The pause node appears three times because that is the clause doing its job. A pause is not a threat. It is a scheduled state with a resume condition, and both sides know it before the build starts.

A Ledger for Every Rupee

I keep milestones in a SQLite ledger on the same ₹600/month VPS that runs the staging Docker container, so no invoice depends on my memory. The schema is deliberately narrow: project, stage, amount, artifact, status, dates. The staging checklist also records P95 latency under 300ms on a 10K-request run, queue depth, and Redis failover status.

CREATE TABLE build_milestones (
  id           INTEGER PRIMARY KEY,
  project      TEXT NOT NULL,
  stage        INTEGER NOT NULL CHECK (stage BETWEEN 1 AND 3),
  amount_inr   INTEGER NOT NULL,
  artifact     TEXT NOT NULL,
  status       TEXT NOT NULL DEFAULT 'pending',
  due_on       DATE,
  paid_on      DATE,
  UNIQUE (project, stage)
);

INSERT INTO build_milestones (project, stage, amount_inr, artifact)
VALUES
  ('surat-catalogue-2026', 1, 80000, 'scope-v3-signed.pdf'),
  ('surat-catalogue-2026', 2, 80000, 'staging-acceptance.md'),
  ('surat-catalogue-2026', 3, 40000, 'handover-runbook.md');

The query I run every Monday:

SELECT project, stage, amount_inr, status,
       COALESCE(paid_on, DATE('now')) AS settled_on
FROM build_milestones
WHERE status != 'paid'
ORDER BY due_on;

If a stage has been pending for more than ten days, I call the client before I send a reminder email. The call is cheaper than the awkward follow-up, and it usually surfaces a real problem rather than a payment problem.

War Story: The Client Who Ghosted After ₹80K

In January 2026 a Surat D2C founder signed a ₹2L build for a catalogue sync and a small admin panel. The first invoice was ₹80,000, paid on time. The staging build passed 31 of 31 acceptance tests. The client asked for "a few small changes" before accepting: a new role, a bulk upload, and a different currency display.

I sent the change order with a price and a revised date. The client went quiet for three weeks. Under a 50/50 contract, I would have had ₹1L and a stalled build. Under the 40/40/20 contract, I had ₹80,000, a signed scope, and a written pause.

I paused the project on day eight. The client returned on day 26, paid the second invoice, and we shipped the original scope without the three additions. The final 20% cleared after handover. The build was profitable, and the relationship survived because the contract made the pause normal.

That project is why I wrote about the three-invoice rule after a client ghosted a ₹2L build. The rule is not about punishing clients. It is about making the exit and the resume path explicit.

When NOT to Use a 3-Stage Contract

Do not use three stages on a ₹55K website. The paperwork costs more than the risk. Use 50/50 and keep the scope to one page. I explain that split in the ₹55K website pricing post.

Do not use this for a monthly retainer. A retainer is a capacity purchase, not a build. Bill monthly in advance with a 30-day notice clause.

Do not use it for government or large enterprise procurement. Their payment terms are usually 30–60 days after invoice, and their acceptance process is not yours to design. Price the delay into the quote or decline the work.

Do not use it when the client cannot name an acceptance owner. If nobody has authority to sign the staging checklist, the second gate will stall. Fix that before signing, not after.

Do not use it as a substitute for a scope document. The percentages protect cash flow, not scope. The scope ledger is still the artifact that prevents the expensive arguments.

Frequently Asked Questions

What is a good deposit for a ₹2L website build in India?

I use 40% on signed scope, 40% on staging acceptance, and 20% on production handover. That collects ₹1,60,000 before the final handover and keeps the last ₹40,000 tied to the runbook and 30-day review. A flat 50/50 works for smaller builds under ₹1L.

Is a 50% deposit better than a 40/40/20 milestone contract?

A 50% deposit is simpler, but it concentrates risk in one acceptance event. The 40/40/20 structure collects 80% before launch and still leaves a meaningful tail. For custom builds above ₹1L, I recommend the three-stage structure.

What happens if a client refuses to accept a milestone?

The contract gives them five business days to accept or reject in writing, with failed test IDs. Work pauses if the invoice is unpaid for seven business days. The pause is a defined state, not a negotiation tactic, and the launch date moves by the paused days.

Can I use this contract for international clients?

Yes, with two changes: state the currency and the payment rail, and set the acceptance window in the client's business timezone. For US clients I use a 7-business-day window and invoice in USD. The milestone percentages stay the same.

Bottom Line

A deposit is not a way to protect yourself from clients. It is a way to make the project's risk visible on both sides. The 40/40/20 structure gives the client three real checkpoints and gives the studio enough cash to keep the team paid while the work is honest. If you are pricing a custom build, read the web development service scope, then revisit the three-invoice recovery story above and the ₹55K website margin math. When your scope is ready, send it to me and I will tell you which stage should carry the most risk.