Software Development Delays and Refund Claims in India: What the Law Actually Says

A software project rarely fails the way people expect it to. It is not usually one dramatic missed deadline. It is a slow accumulation of change requests, extended sprints, a client who stops responding to review calls, and a final product that looks nothing like the wireframe everyone signed off on eighteen months ago.

When that project ends in a dispute, both sides tend to reach for the same two words. The client says "breach." The developer says "scope creep." Indian law does not automatically side with either. It looks at the contract, the conduct of both parties, and the paper trail they left behind.

This piece looks at how software development disputes actually play out under Indian law, from the contract stage through to a refund claim or a courtroom.

Fixed Scope vs. Agile: Where Does the Contract Actually Draw the Line?

A fixed scope contract fixes three things at the start: what will be built, when it will be delivered, and what it will cost. Change is the exception, handled through a formal variation.

Agile development works differently. Requirements evolve sprint by sprint. The client reviews working software at short intervals and gives feedback that shapes the next sprint. Nobody expects the final product to look exactly like the first backlog.

That flexibility is genuinely useful for building better software. It is not a legal shield. Calling a project "agile" in the contract does not excuse a developer who simply misses deadlines, under-resources the team, or delivers broken code. Agile changes how requirements evolve. It does not lower the developer's duty to deliver competent, timely work. Indian courts will still ask what was actually promised and whether it was performed with reasonable care and skill, regardless of the methodology label used in the SOW.

What Should a Software Development Agreement or SOW Actually Cover?

Most software disputes trace back to gaps in the contract itself. A well-drafted Software Development Agreement, read with its Statement of Work, should nail down:

1. Scope and specifications- functional requirements, user stories, or wireframes attached as schedules, not just described in prose.
2. The project timetable and whether dates are firm deadlines or estimates subject to revision. This single distinction decides most delay disputes.
3. Deliverables and exclusions- what is in scope, and, just as importantly, what is explicitly out of scope.
4. Client dependencies- access, data, approvals, and third-party integrations the developer needs from the client to stay on schedule.
5. Milestones and acceptance criteria- objective, testable conditions for when a milestone is deemed complete.

Where these are vague, both sides end up arguing from memory and WhatsApp screenshots. Where they are specific, the dispute usually resolves itself before it reaches arbitration.

Scope Creep: When the Client Keeps Changing Requirements

Evolving requirements are normal in agile work. The problem arises when changes pile up without anyone tracking their effect on price or timeline.

A formal change control clause typically requires that any new requirement be documented, estimated for cost and time impact, and approved in writing before work begins. In practice, though, a lot of change happens informally, over email, in sprint planning calls, through Jira tickets, or simply because the client asked for it in a Slack message and the developer built it.

Indian contract law does not require a signed change order for a variation to count. Conduct can amend a contract just as clearly as a signature can, provided there is evidence the parties actually agreed to the change. This is precisely why contemporaneous records matter. A developer who logs the added Jira tickets, the extra sprint hours, and the client's written approval at the time the change happens is in a far stronger position than one who tries to reconstruct that history after a dispute has already started.

When Does Delay Become a Breach of Contract?

Under the Indian Contract Act, 1872, this comes down largely to whether time was of the essence of the contract. Section 55 says that if time was intended to be essential, the innocent party can treat the contract as voidable on missed deadlines. If it was not, the delay does not void the contract, but the party who caused it still owes compensation for the loss actually suffered.

Whether time is of the essence is not decided by a single clause saying so. The Supreme Court, in Welspun Specialty Solutions Ltd v. Oil and Natural Gas Corporation Ltd, held that an explicit "time is of the essence" clause is not, by itself, conclusive. Courts look at the contract as a whole and the surrounding circumstances to decide whether the parties truly intended strict deadlines.

Delay attribution also matters more than the mere fact of delay. If a developer missed a milestone because the client sat on approvals for three weeks, or failed to provide API access, or kept adding features mid-sprint, that delay is not squarely the developer's fault. Courts and arbitrators routinely apportion responsibility for delay between the parties rather than pinning it entirely on whoever missed the final date. The Supreme Court's ruling in Unibros v. All India Radio is a useful reminder here too: even where delay is proven, a claim for consequential loss such as loss of profitability needs actual evidence of harm, not just the fact that the project ran late.

Can a Client Get a Refund of Milestone Payments Already Paid?

Not automatically. This is where clients most often overreach, and developers most often under-document.

Software payments usually fall into a few distinct buckets, and each behaves differently in a dispute:

These are general tendencies, not fixed rules. The actual outcome in any dispute depends on the specific contract wording, how much of the work was genuinely performed, whether acceptance was given, the termination provisions invoked, and the circumstances surrounding the alleged breach.

These payments raise three separate legal questions, and it helps to keep them apart. Section 73 governs ordinary damages: compensation for loss that naturally flows from a breach, which the claiming party must generally prove. Section 74 governs liquidated damages, a sum the contract itself names in advance. Here, the case law is genuinely split on how much proof of loss is required. ONGC v. Saw Pipes Ltd., (2003) 5 SCC 705, held that where loss is hard to quantify and the parties pre-estimated it in good faith, the injured party need not prove the exact figure. Kailash Nath Associates v. Delhi Development Authority, (2015) 4 SCC 136, building on the older Fateh Chand v. Balkishan Dass, AIR 1963 SC 1405, took a stricter view: some loss or legal injury must still be shown, even if its precise quantum need not be. Which strand a court leans on tends to depend on the kind of clause and facts in front of it, so neither case should be read as settling the question outright.

Refund of a milestone or advance payment is a third, distinct question. It isn't automatically resolved by a Section 74 damages analysis. It turns instead on what the payment was for, how much of that work was actually delivered or accepted, and what the contract's own termination and payment provisions say. A client seeking a refund and a developer resisting a damages claim are, legally speaking, arguing two different points, even though they surface in the same dispute.

In practice, this means a client cannot demand every rupee back just because the final product wasn't fully delivered. Work that was genuinely completed, accepted, or actively used has value, and Indian courts are reluctant to ignore that value even in a failed project. The client's stronger argument is usually a specific one: this milestone was paid for, this deliverable was never accepted, and therefore this specific amount should come back. A blanket "refund everything" claim rarely survives contact with the contract's own payment schedule.

Why Acceptance Testing and UAT Decide Most of These Disputes

Acceptance procedures are the single most underrated clause in software contracts. A clear UAT process defined test cases, a fixed window for the client to test, a written acceptance or rejection, and a defect remediation period for anything that fails, creates a paper trail that resolves most disputes before they escalate.

Problems show up when the client accepts a module, pays the associated milestone, keeps using it in production for months, and only later claims it was never properly delivered. Continued use after acceptance, especially paid use, is difficult to walk back. It signals that the client treated the deliverable as functional at the time, whatever position they take once the relationship sours.

Can a Developer Charge for Work Done Outside the Original Scope?

Yes, but the developer has to prove the work was actually authorised and actually outside scope.

Where a contract already fixes a price for the work in question, that price governs, and a developer cannot bypass it by claiming a separate quantum meruit payment. Where genuinely new work was requested and no price was fixed for it, Section 70 of the Contract Act provides a remedy: if a person lawfully does something for another, not intending it gratuitously, and that person accepts the benefit, they are bound to compensate for it. This is the statutory basis for quantum meruit claims in India, and the Supreme Court applied it in Food Corporation of India v. Vikas Majdoor Kamdar Sahkari Mandli Ltd, awarding compensation for work that conferred a benefit beyond the contract's scope.

The catch is evidence. A developer who wants to be paid for extra work needs to show the client actually asked for it and knew it fell outside the SOW, through emails, revised sprint plans, Jira tickets, or a client sign-off on a change request. Courts have been far less sympathetic where a developer simply decided, on its own initiative, that certain additional work was necessary. Where the parties are bound by a contract with its own pricing mechanism, Indian courts have also been reluctant to let a party sidestep that mechanism using Section 70, since the provision is meant to fill gaps left by the contract, not to override it.

Termination Midway: What Happens to Fees, Code and IP

A properly drafted contract will specify termination rights, notice periods, and what happens to fees already paid. In the absence of clear drafting, Indian courts have sometimes required a reasonable notice period before termination even where the contract doesn't spell one out.

On unfinished software, the general position is that the developer is entitled to be paid for work genuinely performed up to termination, subject to the contract's own payment mechanics.

IP ownership deserves more attention than it usually gets in Indian SOWs, because the statutory default surprises most clients. Under Section 17 of the Copyright Act, 1957, the creator of a work is its first owner. The exception that makes an employer the automatic owner (Section 17(c)) applies only to a genuine employee under a contract of service, not to an independent vendor, freelancer, or development company engaged under a contract for service. That means if the SOW is silent, the developer, not the paying client, is the default copyright owner of the code written for the project. Client ownership has to be created, through a written assignment under Section 19 of the Copyright Act, which must specify the rights, duration, and territory; if these are left blank, the assignment is deemed to last five years and be limited to India, as the Delhi High Court confirmed in Pine Labs Private Limited v. Gemalto Terminals India Limited.

A well-drafted agreement should also separate out a few distinct categories rather than treating "the code" as one undifferentiated asset: pre-existing or background IP (frameworks, internal libraries, or tools the developer brings to every project, which usually stay with the developer under licence); IP created specifically for this project (which the assignment clause should cover); third-party and open-source components (governed by their own licence terms, which can restrict how the client uses the final product regardless of what the SOW says); source-code access and handover (a practical, operational matter, distinct from who legally owns the code); and assignment versus licence (an assignment transfers ownership outright, a licence only grants a right to use, and SOWs that use "licence" language when the client actually wants to own the product create exactly this kind of dispute).

Transition obligations, handing over documentation, credentials, and a working build, are worth spelling out separately from both ownership and termination, since termination clauses often stay silent on what happens in the following thirty days.

Do Limitation of Liability Clauses Actually Protect You?

Usually, yes, but not unconditionally. Liability caps and exclusions of indirect or consequential loss are enforceable under Indian contract law, subject to the same principles that govern any other contractual term: they must be part of a validly formed contract, not unconscionable, and not an attempt to exclude liability for fraud. Whether a specific cap survives a specific dispute depends heavily on drafting quality and the facts, so it is worth resisting the temptation to treat any boilerplate cap as bulletproof. A refund claim and a damages claim are also legally distinct routes, and a liability cap drafted to limit "damages" does not automatically extend to a restitutionary refund claim unless it is drafted to cover both.

Which Evidence Actually Wins These Disputes?

Software disputes are decided almost entirely on documentary evidence such as emails, WhatsApp or Teams messages, Jira or Azure DevOps tickets, Git history, sprint plans, meeting notes, change logs, UAT records, release notes, and invoices.

Since 1 July 2024, the admissibility of this kind of electronic record is governed by Section 63 of the Bharatiya Sakshya Adhiniyam, 2023, which replaced Section 65B of the Evidence Act, 1872. Primary electronic evidence, broadly, the original device or record itself, remains admissible without a certificate. Secondary electronic evidence, such as a printed email chain, an exported chat log, or a copied Jira export, needs a certificate under Section 63(4), now in the prescribed Schedule format, signed by both the person in charge of the device and an independent expert, and stating the record's hash value. This dual-certification requirement is new to Section 63; Section 65B required only one signatory. Anvar P.V. v. P.K. Basheer, (2014) 10 SCC 473, and Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal, (2020) 7 SCC 1, were decided under the earlier Section 65B and are not direct authority on Section 63's new certificate format. They remain useful background, since Section 63 retains 65B's core structure and courts are likely to draw on the same reasoning on why a certificate is mandatory and cannot be substituted by oral evidence. Parties who assume their Slack export or Jira printout will simply be accepted at trial without this paperwork are often in for an unpleasant surprise.

Are Founders and Directors Personally Liable?

Generally, no. A private limited company is a separate legal entity, and a breach of a software contract by the company is the company's liability, not its directors'. Personal liability attaches only in specific situations such as a personal guarantee, a direct indemnity signed by an individual, or circumstances where a director has expressly undertaken a personal obligation. Absent that, a client frustrated with a failed vendor cannot simply redirect the claim to the vendor's founders.

Contract Drafting Lessons from Sophisticated Technology Agreements.

Well-drafted international technology agreements tend to formalise several mechanisms that Indian SOWs would benefit from adopting more consistently, not because Indian law requires a different approach, but because clear drafting prevents the disputes this article has been describing.

The deemed-acceptance clock is probably the single most useful addition for Indian SOWs: it removes the ambiguity of a client who neither rejects nor accepts a deliverable, and only raises non-performance months later once the relationship has already broken down.

What to Do When the Project Has Already Gone Wrong

If you're a founder or business already past the point of prevention, the priority shifts from avoiding a dispute to positioning yourself well within the one. Before sending a termination notice, refund demand, or legal notice, it's worth doing the following:

1. Pull together the Agreement and SOW, along with every amendment, however informal, and keep them in one place.
2. Preserve emails, and WhatsApp, Teams, or Slack threads relevant to scope, delay, or acceptance, rather than relying on memory of what was said.
3. Export the relevant Jira or Azure DevOps history before access is lost or revoked.
4. Preserve Git or repository history, since commit timestamps and logs are often the clearest record of what was actually built and when.
5. Map every payment made against the specific milestone or deliverable it was tied to.
6. Separate what was in the original scope from what arrived later as a change request, and note how each change was approved.
7. Go through the delay chronology and identify, honestly, which delays trace back to which party.
8. Record the acceptance, rejection, or continued use of each deliverable, since this often decides the dispute on its own.
9. Check what source code and IP access currently exists before triggering termination, since access can become a bargaining chip once notice is sent.
10. Review the notice period, governing law, and dispute-resolution clause carefully before acting, since taking a step that doesn't comply with the contract's own procedure can weaken an otherwise strong position.

This groundwork usually takes a few days. Skipping it to send a notice faster almost always costs more time later.

Practical Steps Before a Software Development Dispute Escalates

For customers:

1. Read the timetable clause carefully; know whether dates are firm or indicative before you rely on them.
2. Put every change request in writing, even if it started as a verbal ask in a call.
3. Test and respond to milestone deliverables within the acceptance window instead of letting it lapse.
4. Don't keep paying and using a module for months and then claim non-performance later, document concerns as they arise.

For technology providers:

1. Log the cost and time impact of every scope change at the time it happens, not after the relationship turns adversarial.
2. Get written sign-off, even informal email confirmation, before building anything outside the SOW.
3. Preserve Git history, sprint records, and ticket logs, they are your evidence if this ends up in arbitration.
4. Send acceptance requests formally, and follow up in writing if the client goes silent instead of assuming silence means approval.

Most software disputes are really documentation disputes wearing a legal label. The side with the clearer paper trail, not necessarily the side with the stronger sense of grievance, tends to walk away with the better outcome.

Frequently Asked questions

1.    Can I get a refund if my software project is delayed in India?

Not automatically. A delay only entitles you to compensation or termination if time was of the essence under the contract, and even then the refund is tied to work not delivered or not accepted, not the full amount paid, especially if some milestones were genuinely completed and used.

2.    Is "agile development" a legal excuse for missing deadlines?

No. Agile explains why requirements evolved, but it doesn't excuse poor execution, under-resourcing, or delivering broken code. Courts still check what was actually promised and whether it was delivered with reasonable skill and care.

3.    What counts as scope creep in a software development contract?

Scope creep is when the client adds or changes requirements beyond what the SOW covers, without a formal change order. It's not illegal by itself, the dispute arises when nobody tracks the added cost or time, and both sides later disagree on what was "in scope."

4.    Can verbal or email approvals count as a valid change request?

Yes. Indian contract law doesn't require a signed change order conduct and written communication (emails, Jira tickets, meeting notes) can establish that a variation was agreed, provided there's a clear record.

5.    When does a delayed software delivery legally become a breach of contract?

A delayed delivery may constitute breach depending on the contractual delivery obligation and responsibility for the delay. Whether time was intended to be of the essence under Section 55 is particularly important in determining the consequences of missing the deadline, including termination/avoidance and compensation. Client-caused delays, missing inputs and agreed scope changes must also be considered.

6.    Can a client demand a full refund of milestone payments already made?

Rarely. Milestone payments tied to completed and accepted work are hard to claw back in full. Refund claims are strongest for payments made "on acceptance" where acceptance was never actually given.

7.    Can a software developer charge extra for work outside the agreed scope?

Yes, if the additional work was genuinely outside the SOW and the client authorised it in writing or through clear conduct. This falls under Section 70 (quantum meruit). Undocumented, self-initiated extra work is much harder to recover payment for.

8.    What happens to the source code if a software contract is terminated midway?

It depends entirely on the contract's IP and handover clauses. Without an explicit assignment clause, ownership can default to statutory copyright rules rather than automatically passing to the client, which is why source-code handover terms matter as much as the termination clause itself.

9.    Are WhatsApp and Slack messages admissible as evidence in an Indian court?

Yes, as electronic records, provided they meet the certification requirements under Section 63 of the Bharatiya Sakshya Adhiniyam, 2023, including the hash value and dual certification for secondary evidence.

10.  Can a company director be personally sued for a software project going wrong?

Generally no. Liability stays with the company unless the director gave a personal guarantee, signed a personal indemnity, or expressly took on an individual obligation.

11.  Can I send a legal notice to a software development company for delay or incomplete work?

Yes. Depending on the contract and circumstances, a legal notice may be used before litigation or arbitration to identify the alleged breaches, invoke relevant contractual provisions, seek cure or other relief, and create a formal record of the dispute. The contract's notice and dispute-resolution provisions should be checked before issuing it.

12.  What can a software company do if a client refuses to pay for additional work outside the original scope?

The developer's position is strongest where the extra work was requested and acknowledged in writing, or through clear conduct such as a revised sprint plan or a Jira ticket the client actively engaged with. Where that evidence exists, the developer can pursue payment under the contract's change-control mechanism or, where none was invoked, under Section 70 of the Contract Act. Without that evidence, recovery becomes considerably harder.

Related Articles

1.    SOFTWARE DEVELOPMENT AGREEMENT IN INDIA: LEGAL RISKS AND HOW TO AVOID THEM

2.    IP Clauses in SaaS Agreements: Why Your Software May Not Be Fully Protected

Reviewed by: This blog was reviewed by Yashvardhan Singh, a legal professional with experience in commercial contracts and technology law. His review focused on the accuracy of the statutory framework discussed in this article, including the Indian Contract Act, 1872 and the Bharatiya Sakshya Adhiniyam, 2023..

Disclaimer

This article is intended solely for general informational and educational purposes. It does not constitute legal advice, advertising, or solicitation. The legal position in a software development dispute depends on the specific contractual terms, the project documentation and communications between the parties, the conduct of both sides, and the particular facts of the dispute. Independent professional advice should be obtained before acting on this information.