The Freelance Contract Checklist I Use Before Saying Yes (India‑Friendly)

Feb 28, 2026

A practical, India‑focused freelance contract checklist for developers: protect your time, payment, IP, and taxes without scaring clients away.

Written by: Rohan Deshpande

I’ll be blunt: most freelance work in India falls somewhere between handshake deals and full‑blown lawyering. Early in my freelancing days I said yes too quickly and learned the expensive way what a missing clause costs. Over the years I built a short, practical freelance contract checklist I use before I sign anything. It’s not a substitute for a lawyer, but it prevents common, painful mistakes—and it usually keeps negotiations friendly.

Main keyword: freelance contract (used below several times)

What this checklist does

• Saves you from unclear scope and scope‑creep (the biggest time sink).
• Protects your invoices and cashflow.
• Keeps IP and liability reasonable.
• Keeps tax/GST realities in view for Indian clients or freelancers.

A quick position: don’t be the developer who treats contracts as a formality. But also don’t turn every contract into a legal barricade that chases away good clients. The sweet spot is clarity and limited risk.

Core checklist (what I read and edit every time)

1. Scope of work (be surgical) Write a short, bulleted list of deliverables and what “done” means. Don’t rely on vague phrases like “feature complete.” Add one line: “Any additional requests beyond this scope will be quoted separately.” This is the single clause that saves the most hours.

2. Milestones and payment schedule Prefer milestone payments (10–30% upfront is reasonable). For 1–3 month projects I ask for 30% upfront, 40% on beta/delivery, 30% on acceptance. For ongoing retainer work I use monthly prepaid invoices. Explicitly name the payment currency (INR vs USD), payment methods (bank transfer/UPI/Payoneer), and a late payment penalty (e.g., 1% per week after 15 days). Be realistic: strict penalties can sour relationships; gentle, enforceable terms work better.

3. Acceptance criteria and revisions Define testing and acceptance windows (e.g., client has 7 calendar days to review; up to two rounds of minor revisions included). Spell out what counts as a revision vs a new feature.

4. Intellectual Property (IP) Decide what you want: full assignment on final paid deliverable, or a license to the client with you retaining reuse rights. For most freelance dev work I assign deliverables on full payment but retain the right to reuse non‑confidential libraries or utilities I created. If the client insists on all‑rights assignment, increase the fee.

5. Confidentiality vs NDA If the project involves sensitive data, either attach an NDA or include a short confidentiality clause. Keep the duration reasonable (1–3 years). Avoid open‑ended confidentiality that forbids you from reusing non‑sensitive patterns.

6. Warranties and liability cap Limit your warranty to fixing functional bugs reported within a short period (30–90 days) and cap liability to the total fees paid. You don’t need to insure catastrophic client losses. This is important for risk control and standard in commercial contracts.

7. Termination and refunds Define how either party can terminate, notice period, and what refund (if any) is due. I usually bill for work done plus any non‑refundable expenses and return deliverables on pro‑rated payment.

8. Taxes and invoicing (India specifics) State fees are exclusive of GST if you’re registered, or mention “GST extra” if applicable. For foreign clients, clarify that the client may need to withhold TDS and that you’ll issue invoices per Indian tax rules. Keep copies of invoices and bank receipts—TDS and GST audits are real.

9. Support and maintenance (post‑delivery) If the client wants ongoing maintenance, convert it to a separate retainer with clear SLA (response times) and scope. Don’t leave open expectations of “small fixes for free.”

10. Dispute resolution & governing law A short clause specifying governing law (India) and dispute mechanism (negotiation → mediation → courts/arb) is useful. For small jobs, keep wording simple: mediation first, litigation only as last resort.

How I introduce these redlines without sounding combative I don’t send a blank legal file. I send a one‑page summary of the scope and payment terms, and say I’ll attach a short contract that mirrors that summary. If a client pushes back on fees because of IP clauses, I trade: either keep IP and lower fee, or assign IP and increase fee. Most professional clients expect this.

Real constraint: time vs perfection Negotiating every clause takes time, and small clients will bail if you make it a litany of legal demands. My tradeoff is: be strict on scope, payment, and liability; be flexible on non‑core clauses like minor wording on confidentiality. You’re protecting your hours and cashflow first.

When to get a lawyer

• High‑value work (>₹5–10 lakh) or equity deals.
• Complex IP (exclusive rights across geographies).
• Long‑term retainers tied to SLAs and penalties. For routine freelance work, a short, well‑phrased contract and clear email trail are usually enough.

A few last, practical tips

• Keep a contract template (one page + signature spots) you can reuse. It saves negotiation time.
• Use UPI or bank transfers and insist on invoices. If a client insists on delayed payment terms, ask for a larger upfront.
• Preserve evidence: emails confirming scope changes, screenshots of approvals, timestamped commits tied to milestones.

Wrap up A good freelance contract doesn’t look like a fortress; it looks like a shared map. It tells you and your client where you’re going, how you’ll get paid, and what happens if one of you changes plans. It protects your time without making every relationship adversarial. It won’t stop every problem—late payers still exist—but it shifts the odds back in your favor.

If you want, I can share the one‑page template I use (plain language, two signatures). It’s the version that survived three missed payments, one scope creep attempt, and one accidental IP tug‑of‑war—and that’s why I trust it.