Software development agreement — build it, test it, own it

What the agreement is for

Software is unusual among things people pay to have made. A builder hired to put up a wall produces something the client can see, measure and touch; a developer produces thousands of lines of instructions that the client usually cannot read, running on servers the client may never see, depending on libraries written by strangers. The client judges the work by whether the screens do what it expected. The developer judges it by whether it did what was asked. When those two expectations were never written down in the same words, the project ends in an argument.

A software development agreement exists to close that gap. It does four jobs. It fixes what is being built, in enough detail that both sides can later point to the same sentence. It fixes how the work will be judged — the tests, the defects that matter, and the moment at which the client says yes. It fixes who owns the result, which the law does not settle in the client’s favour by default. And it fixes what happens when things go wrong: delay, a change of mind, a developer who leaves, a client who stops paying.

This page covers projects in which software is built to order: a website or online store, an Android or iOS app, a web platform, an ERP customisation, an integration between systems, an internal dashboard. Where software already exists and the customer merely subscribes to it, the better model is a SaaS subscription agreement; where a customer installs a finished product, an end user licence agreement. Many real projects touch all three, and we come back to that overlap below.

If the finished product will be sold to many users as installed software, the terms on which those users receive it — licence model, keys, updates, restrictions — are explained in our end user licence agreement guide.

Agency, freelancer or in-house?

The type of developer changes which clauses carry weight.

For a single freelancer on a small, one-off job, our freelance agreement guide is the better starting point: it deals with the law on ownership, the Section 19 defaults, MSME payment protection and foreign clients in depth, and this page does not repeat those explanations. For code written by employees, see the intellectual property section of our employment agreement guide; for a co-founder’s code, see moving the work into the company.

Master agreement and statements of work

When a client and a developer expect to work together on more than one project, or on a project with several phases, the neatest structure is a master services agreement with separate statements of work. The master agreement contains the legal terms that do not change — ownership, confidentiality, warranties, liability, termination, disputes. Each statement of work describes one piece of work: its scope, deliverables, timetable, team, price and acceptance criteria.

For a single, self-contained project, one agreement with the scope in a schedule is enough. Either way, the documents need an order of precedence for conflicts. The usual rule is that a statement of work prevails on commercial and technical points specific to that project, and the master agreement prevails on legal points, unless the statement of work expressly says it is changing a named clause of the master agreement. Without such a rule, a line in a hastily written statement of work — “client will own all materials” — may be argued to override a carefully negotiated licence of background code.

Writing the requirements

Every other clause depends on this one. Acceptance tests are measured against the requirements; the fixed price is calculated from them; a change request is anything outside them; a warranty claim is a failure to meet them. Vague requirements make every later clause arguable.

A useful requirements document, sometimes called a software requirements specification, does not need to be long, but it should cover:

• Purpose and users. What the software is for, who will use it and in what roles — customer, staff, administrator, delivery partner.
• Functional requirements. What each user must be able to do, written as features or user stories: “A buyer can track each order by its purchase order number and see its current production stage.”
• Platforms. Web browsers, Android and iOS versions, screen sizes, and whether the app is native, cross-platform or a progressive web app.
• Integrations. Payment gateways, SMS and email providers, accounting software, maps, logistics partners, government portals, existing databases — and who supplies the access.
• Non-functional requirements. Speed, the number of simultaneous users, availability, languages, accessibility, security standards, data retention.
• Data migration. Whether existing data must be moved into the new system, in what format, and who cleans it.
• Assumptions and dependencies. What the price assumes — for instance, that the client supplies all content and third-party accounts within agreed dates.
• Exclusions. What is not included: content writing, photography, hosting fees, app store fees, marketing, future operating system updates.

Where requirements are genuinely unknown at the start — a new product whose shape will be discovered by building it — it is better to say so honestly and choose a pricing model that allows for discovery, than to write a specification that pretends to certainty. A paid discovery phase, in which the developer and client produce the requirements together for a fixed fee before the main build is priced, is common and sensible.

Fixed price, time and material, or sprints

The pricing model decides who carries the risk that the work takes longer than expected.

Each model needs its own protections. A fixed price contract needs precise requirements and a firm change request process, because every disagreement becomes a question of whether something was included. A time and material contract needs rate cards, timesheets the client can inspect, a monthly budget or cap above which the developer must stop and ask, and a right for the client to reject time spent on work it never requested. An agile contract needs clarity about what the client receives at the end of each sprint, who owns the product backlog, and how either side can stop after any sprint without penalty.

Milestones and payments

Payment terms in software contracts do two jobs: they fund the developer’s work, and they give the client leverage to ensure the work is finished. A balanced schedule does both. A common fixed price structure looks like this:

Whatever the shares, tie each payment to something objective. “On completion” is not objective. “Within seven days of the acceptance certificate or deemed acceptance under clause 9” is.

The agreement should also set invoice timing, the period for payment, interest on late payment and the developer’s right to pause work after a stated period of non-payment and written notice. A developer registered as a micro or small enterprise has statutory rights to payment within a fixed time and to compound interest on delay, explained in our freelance guide’s MSMED Act section; practical invoicing techniques are in payment terms that actually work. A developer that has paused work for non-payment should not be liable for the resulting delay, and the agreement should say so.

Change requests

Requirements change in every real project. Users test an early version and ask for something different; the business changes its mind; a regulator or a payment gateway changes its rules. Change itself is not the problem. The problem is change that nobody records, so that at the end one side believes it paid for everything and the other believes it did twice the work.

A change request clause sets out a simple procedure:

1. Either side may propose a change in writing, describing what is wanted.
2. The developer responds within a stated number of working days with its effect on scope, price, timetable and any other part of the project, such as testing or security.
3. The change proceeds only when both sides sign or approve the change request in writing, including by email from named representatives.
4. Until then, the developer continues with the agreed scope, and is not obliged to begin the change.
5. Approved changes form part of the requirements, and acceptance tests are updated accordingly.

Two practical points make the clause work. First, name the people on each side who can approve changes. A client’s junior employee asking for “one small thing” on a messaging group should not bind the client to pay for it, and a developer’s junior engineer should not quietly agree to it either. Second, allow small changes to be absorbed: many agreements let the developer accommodate minor adjustments up to a stated number of hours without a formal request, so the process does not become bureaucratic. Our freelance guide discusses revision rounds for creative work; the principle here is the same but more formal, because software changes ripple into testing and timelines.

What the client must provide

Many delays in software projects are caused not by developers but by clients who do not supply what the developer needs: content, product images, approvals, access to an old database, test accounts with a payment gateway, credentials for a courier’s interface, a decision about the colour of a button. The agreement should list the client’s obligations as carefully as the developer’s:

• Provide content, data, branding and materials by stated dates.
• Nominate a project manager with authority to answer questions and approve work.
• Review and respond to designs, builds and queries within stated periods.
• Obtain and pay for third-party accounts, licences and approvals that the project depends on.
• Provide test environments, sample data and access to existing systems.
• Make key staff available for workshops and testing.

The consequence of the client’s delay should be stated: the timetable extends by the period of delay, the developer is not liable for the resulting lateness, and if the delay exceeds a stated period, the developer may charge for idle time or reschedule the team. Without this, a delay-damages clause can end up penalising the developer for the client’s own slowness.

Testing and acceptance

Acceptance is the moment the client agrees that the software meets the requirements. It usually triggers a large payment, starts the warranty period, and sometimes transfers ownership. So the process of reaching it must be clear.

Testing stages. The developer tests its own work first — unit tests, integration tests and its own quality assurance. It then delivers a build to a test or staging environment with release notes, and the client carries out user acceptance testing against the agreed requirements and test cases. Agreeing the acceptance test cases in advance, even as a simple list of scenarios, removes most arguments.

Defect severity. Not every defect should block acceptance. A common classification:

The acceptance cycle. The client tests for a stated period, such as ten working days, and reports defects in writing with enough detail to reproduce them. The developer fixes them within the agreed times and redelivers. The client retests, normally only the fixed items and anything they affect. The agreement should limit the number of cycles and say what happens if critical defects remain after, say, three rounds: usually a right for the client to terminate that phase and recover sums paid for it, or to accept with a price reduction.

Deemed acceptance. To stop acceptance being delayed indefinitely, the software is treated as accepted if the client does not report blocking defects within the testing period, or if it starts using the software in live operation with real users or customers. Clients should make sure the testing period is realistic, and that a short trial with a few staff is not counted as live use. Developers should make sure that “going live” is defined so that a client cannot run its business on the software for months while refusing to accept it.

Acceptance is not waiver. Acceptance means the software met the requirements as far as reasonable testing could show. It should not prevent the client from relying on the warranty for defects discovered later, and the agreement should say so.

Who owns the code

Many clients assume that if they pay for software, they own it. Indian copyright law does not work that way. A computer programme is a literary work under the Copyright Act, and its author is the first owner of the copyright. The exception for work made under a contract of service applies to employees, not to independent developers or agencies working under a contract for service. So unless there is a written assignment, the developer owns the copyright in the code it wrote, and the client has at most an implied licence to use what it received for the purpose for which it was commissioned. The detail of this rule, and the statutory defaults that apply to an assignment that is silent on duration or territory, are set out in our freelance guide on Section 17 and Section 19.

For a software project, the ownership clause should say:

• What is assigned. All code, designs, documentation, database structures, test scripts and other materials created specifically for the client under the agreement — often called “deliverables” or “foreground IP”.
• What is not. The developer’s background IP and third-party components, which are licensed rather than assigned (see the next two sections).
• When it passes. Commonly on payment of the fee for the relevant milestone. This protects the developer against a client who takes the code and does not pay, while ensuring the client owns what it has paid for.
• The scope of the assignment. Worldwide, for the full term of copyright, including all rights of reproduction, adaptation, commercial rental and communication, with the right to modify and sublicense.
• Moral rights. An undertaking by the developer not to assert its rights of attribution and integrity in a way that interferes with the client’s use, and to obtain the same from its individual developers.
• The developer’s own people. A promise that every employee and subcontractor who worked on the project has assigned their rights to the developer, so that the chain of title is complete.
• Further assurance. An obligation to sign any further documents needed to register or enforce the rights, such as a copyright registration or a filing abroad.

Ownership of the code is separate from ownership of the product’s name and logo, which are protected as trade marks. If the developer or its designer created the brand, the assignment should cover the artwork, and the client should file its own trademark application rather than rely on the developer’s goodwill.

Code written with AI tools. Developers increasingly use AI coding assistants. The law on whether, and to whom, copyright attaches to machine-generated code is unsettled in India and abroad, and the terms of the AI tools themselves vary. A cautious agreement requires the developer to disclose significant use of such tools, to review and take responsibility for all code delivered as if written by hand, not to enter the client’s confidential code or data into tools that train on inputs, and to give the same warranties regardless of how code was produced. This is an area in which terms should be reviewed as the law develops.

Background IP and reusable components

A developer does not start every project from a blank screen. Agencies build up their own frameworks, templates, modules for login, payments or notifications, deployment scripts and internal tools; that is part of why they can deliver quickly. If every client acquired ownership of those components, the developer would lose the ability to use them for the next client, and would have to price every project as though writing everything afresh.

The usual solution is to divide the IP in two. Background IP — what the developer owned before the project or develops independently of it — stays with the developer. Foreground IP — what is created specifically for the client — is assigned to the client. Where background IP is built into the deliverables, the client receives a licence to it that is:

• perpetual and irrevocable, so that it survives the end of the relationship;
• royalty-free, because the project fee has paid for it;
• wide enough to use, copy, modify and maintain the software, including through another developer; and
• transferable with the software, so that the client can sell its business or the product.

The agreement should list significant background components in a schedule, so there is no later argument about whether a module was pre-existing. It should also deal with general know-how: the skills and techniques the developer’s team learns while working on the project. It is normal for the developer to remain free to use general know-how, but not the client’s confidential information, business logic or distinctive features.

Open source licences

Nearly all modern software is built on open source components: programming frameworks, databases, user-interface libraries, encryption libraries. That is not a defect; it is how software is built. But each component comes with a licence, and the licence terms travel with the software.

This table is a simplification; the effect of a licence depends on how a component is used and on the exact licence text, and specialist advice should be taken where a copyleft component is central. For contract purposes, the agreement should:

• require the developer to use only open source components whose licences are compatible with the client’s intended use and distribution;
• prohibit strong or network copyleft components without the client’s written consent;
• require a list of all open source components, their versions and licences on delivery — a software bill of materials — and keep it updated through maintenance;
• require compliance with licence notices, for example an “open source licences” screen in the app; and
• exclude open source components from the assignment, since the developer cannot assign what it does not own, while warranting that their use complies with their licences.

Repositories, accounts and credentials

The most common way clients lose control of their software is not through a legal technicality but through accounts. The code sits in the developer’s repository; the app is published from the developer’s store account; the domain is registered in the developer’s name; the cloud server is billed to the developer’s card. When the relationship ends badly, the client discovers that owning the copyright does not help much if it cannot get at the code or the servers.

The remedy is simple and should be written into the agreement: the client creates and owns the accounts, and gives the developer access.

Where the developer has already created accounts, the agreement should oblige it to transfer them — app stores and cloud providers have their own procedures for moving an app or a project from one account to another, and they can take time and meet conditions — and until then to hold them for the client. On any termination, the developer should hand over all credentials, remove its own access when asked, and confirm in writing that it has done so. Credentials should be shared through a password manager or secure channel, never in chat messages, and rotated when team members leave.

Publishing from the right account is also the first step in passing store review; the other documents the stores expect are listed in our app store compliance guide.

Designs, content and third-party assets

Designs, icons, fonts, photographs and written content each have their own owner and licence. The agreement should say that the developer will use only assets it is entitled to use for the client’s purpose, will list paid stock assets and fonts with their licence terms, and will buy commercial licences in the client’s name where needed, or tell the client that it must. Content supplied by the client remains the client’s responsibility: the client warrants that it has the right to use it and indemnifies the developer if it does not. If the developer writes content, such as product descriptions or legal pages, the assignment should cover it too — though legal pages such as privacy policies and terms of use should be prepared for the client’s actual business, not copied from another site; our website legal pack exists for that reason.

Security and quality standards

Security is easiest to build in and hardest to add later, and it is one of the areas where the developer knows much more than the client. The agreement should turn general expectations into specific obligations:

• Secure development practices, such as protection against the common web and mobile vulnerabilities catalogued by widely used industry lists, input validation, and secure handling of passwords and sessions.
• Encryption of data in transit and of sensitive data at rest.
• No hard-coded secrets: keys and passwords kept in configuration or a secrets store, never in the code repository.
• Role-based access in the software itself, with administrator functions protected.
• Logging sufficient to investigate incidents, kept for an agreed period.
• Dependency updates for known vulnerabilities in libraries during the warranty and maintenance periods.
• Security testing before go-live — a vulnerability scan at least, and for sensitive systems an independent penetration test, with critical findings fixed before acceptance.
• Incident notice: the developer must tell the client promptly of any security incident affecting the software or the client’s data, so that the client can meet its own reporting duties, which under the CERT-In directions can be very short.

Personal data and confidentiality

Developers see a great deal. During a project they may receive customer lists, sales data, pricing, business plans and access to live systems holding personal data. Two sets of terms are needed.

Confidentiality. The developer must keep the client’s confidential information secret, use it only for the project, share it only with team members who need it and are bound by the same duty, and return or destroy it at the end. The client, in turn, must protect the developer’s confidential information, such as its pricing and its background code. If the project is still being discussed, a separate non-disclosure agreement can protect the early conversations.

Personal data. Under the Digital Personal Data Protection Act, 2023, the business that determines the purpose and means of processing is the data fiduciary, and it remains responsible for processing done on its behalf. A developer that handles personal data for the client — by testing with real records, migrating data, or hosting and maintaining the software — is a data processor, and the Act contemplates that the fiduciary engages processors under a valid contract. Our DPDP privacy policy guide explains what that contract should cover; for larger engagements, a separate data processing agreement is usual. In the development agreement itself, the practical points are:

• use anonymised or dummy data for development and testing wherever possible;
• where real data is needed, limit it to what is necessary and keep it only in client-approved environments;
• no copying of personal data to personal laptops, personal cloud drives or overseas servers without consent;
• prompt notice of any breach, with cooperation in the response; and
• deletion of personal data at the end of the engagement, with written confirmation.

Key personnel, subcontracting and non-solicit

A client often chooses an agency because of the people it met during the pitch: the senior architect, the lead designer, the project manager. Then the project is staffed by others. A key personnel clause names the people who will work on the project in stated roles, requires the developer to keep them on it except for reasons beyond its control, such as resignation or illness, and requires any replacement to have comparable skills and to be introduced at the developer’s cost, including the time needed to hand over.

Subcontracting should need the client’s consent, particularly for offshore subcontractors or for any subcontractor that will see personal data. The developer should remain responsible for its subcontractors’ work as if it were its own, and should make sure the subcontractors have assigned their rights, so that the chain of title for the code has no gaps.

Agencies often ask for a non-solicitation clause preventing the client from hiring the agency’s developers directly during the project and for a period afterwards. A clause of reasonable scope protects the agency’s investment in its team; but Indian law treats agreements in restraint of trade with suspicion, and a provision that effectively stops an individual from taking a job may not be enforceable. A common compromise is a placement fee payable if the client hires a named team member within a stated period, rather than an outright prohibition. Clients should resist non-solicit clauses that go beyond the people actually assigned to their project.

Delay and liquidated damages

Software is often late. Sometimes that is the developer’s fault, sometimes the client’s, and often both. The agreement should first make the timetable meaningful: dates for each milestone, a procedure for extending them when the client is late or changes are approved, and a duty on the developer to warn early if a date is at risk, with a recovery plan.

Some clients, especially where a launch date matters commercially, want liquidated damages for delay: a pre-agreed sum, such as a percentage of the milestone fee for each week of delay, up to a cap. Such a clause gives both sides certainty. Under Section 74 of the Indian Contract Act, however, a stated sum is treated as the upper limit of compensation rather than an automatic entitlement, and courts award reasonable compensation within it; our service level agreement guide discusses the same principle in relation to service credits. Clauses should be drafted as a genuine estimate of loss, capped, and stated to be the client’s exclusive remedy for delay unless the delay becomes long enough to justify termination.

Warranty and bug fixing

No software of any size is free of bugs, and a good agreement does not pretend otherwise. It gives a limited warranty and a clear remedy.

A typical developer’s warranty promises that:

• for a stated period after acceptance — commonly between one and three months, sometimes longer for complex systems — the software will perform materially in accordance with the requirements;
• the work will be carried out with reasonable skill and care by suitably qualified people;
• the deliverables will not, to the developer’s knowledge, infringe anyone else’s intellectual property;
• the software will not contain deliberately harmful code, such as hidden back doors, time bombs or code that disables the software if a payment is late; and
• open source components have been used in accordance with their licences.

The remedy for a breach of the software warranty is usually that the developer will fix reported defects free of charge within the agreed times, and if it cannot, refund the fee for the defective part. The warranty should exclude problems caused by changes made by the client or others, use on unsupported devices or platforms, third-party services outside the developer’s control, and misuse. It should also be clear about operating system and browser updates released after acceptance: adapting to them is maintenance, not warranty.

The prohibition on harmful code deserves emphasis. Developers sometimes consider inserting a “kill switch” to protect themselves against non-payment. This is a bad idea legally and commercially: interfering with a computer system without authority can attract liability under the Information Technology Act, and it destroys trust. The proper protections for a developer are milestone payments, assignment on payment and the right to pause work.

Hosting, maintenance and support

The end of development is the beginning of the software’s life. It will need hosting, security updates, adaptation to new operating system versions, bug fixes after the warranty ends, and new features. These are usually covered by a separate annual maintenance agreement or a maintenance schedule, rather than folded into the development fee.

A maintenance schedule should state what is included: corrective maintenance (bug fixing), adaptive maintenance (keeping the software working as platforms change), preventive maintenance (security patches and dependency updates), and a stated number of hours for small enhancements. It should state when and how support can be reached and how fast each class of problem is answered, hosting responsibilities if the developer manages the servers, backups and restoration testing, and the fee and how it changes each year. Where availability and response times are measured and credited, those terms belong in a service level agreement, and our guide explains how service credits work.

If the developer will not only build the software but also run it and provide it as a service to the client and its users, the relationship has become closer to a software subscription. Our SaaS guide’s section on implementation explains how build work fits alongside a subscription, and its intellectual property section explains why ownership then works differently: the customer normally owns its data and configurations, while the provider keeps the platform.

Liability and indemnities

Developers commonly cap their liability at the fees paid under the agreement, or under the relevant statement of work, and rule out claims for lost profits, lost business and other indirect loss. That is normal, and without it few developers could take on projects for businesses much larger than themselves. Clients should check what the cap leaves out, because some matters are usually treated separately:

• Intellectual property indemnity. If a third party claims that the deliverables infringe its rights, the developer defends the client and bears the cost, or modifies or replaces the infringing part. This indemnity is often outside the cap, or subject to a higher one.
• Confidentiality and data breaches caused by the developer, which are often subject to a separate, higher cap.
• Fraud, wilful misconduct and deliberately harmful code, which cannot sensibly be capped.
• The client’s payment obligation, which the cap should not reduce.

The client, in turn, usually indemnifies the developer against claims arising from content and materials the client supplied and from the client’s use of the software in breach of law. Both indemnities should require prompt notice of the claim and allow the indemnifying party to control the defence.

Termination and handover

A project can end early for good reasons — the client’s business changes, funding runs out, or it decides to take development in-house — or bad ones. The agreement should provide for both:

• For convenience: the client may end the agreement on notice, paying for work done up to termination, for committed third-party costs, and sometimes a modest fee for the developer’s lost planned work.
• For breach: either side may terminate if the other commits a material breach and does not remedy it within a stated period after notice.
• For insolvency, or where the developer abandons the project.
• By the developer for non-payment, after notice and a cure period.

What happens after termination matters more than the grounds. On any termination, the developer should deliver all work in progress in its current state — source code, designs, documentation, database schemas, build and deployment scripts — together with credentials and access, and provide reasonable handover assistance to the client or a new developer for a stated period, at agreed rates where the handover is not caused by its own breach. Ownership of work in progress should pass on payment for it. Confidentiality, the IP clauses, the warranty for accepted work, and dispute resolution should survive termination.

A handover checklist, attached to the agreement, makes this concrete: repository access confirmed, a successful build from the repository by the client’s nominee, environment variables and secrets transferred, domains and store accounts in the client’s name, third-party subscriptions transferred, documentation delivered, the developer’s access removed. If the other side refuses to cooperate, a legal notice setting out exactly what is owed under the agreement is usually the first step.

Source code escrow

Sometimes the client will not receive the source code at all. A developer may license an existing product with customisations, keeping the code; or a software vendor may supply a system on which the client’s business depends. The client’s risk is that the vendor stops supporting the software, goes out of business or is acquired, leaving the client with a system nobody can fix.

A source code escrow arrangement addresses this. The vendor deposits the source code and documentation with an independent escrow agent, updates the deposit with each major release, and the agent releases the code to the client if defined events occur — insolvency, cessation of business, or failure to provide maintenance after notice. The arrangement is set out in a three-party agreement. It is worth insisting on two things: that the deposit is verified from time to time, to show that it can actually be built into working software; and that the release events are objective, so that the client does not have to prove a dispute before it can get the code.

GST, TDS and foreign clients

Software development and related IT services are generally taxable supplies of services under GST when the supplier is registered, and the rate should be stated as extra to the fee unless the fee is expressly inclusive. A developer registered under GST should issue tax invoices in the proper form. When services are supplied to a client outside India, they may be zero-rated as an export of services if the statutory tests are satisfied.

Indian clients may be required to deduct tax at source from payments to developers, at rates that depend on how the payment is characterised, and the income tax law has been recodified with effect from April 2026, so section references in older contracts should be checked. The agreement should say that the client will deduct only as the law requires and issue certificates promptly, so the developer can claim credit. These are matters for your chartered accountant, and we do not give tax advice.

With a foreign client, the agreement should settle currency, exchange rate risk, bank charges, the governing law and the forum for disputes. Our freelance guide’s section on foreign clients covers the practical side of being paid from abroad.

Stamp duty and signing

Stamp duty on a development agreement depends on the state where it is signed; for a general agreement it is usually small. Stamping it properly means it can be admitted in evidence without first paying a penalty if a dispute ever arises. In Delhi, duty can be paid through e-stamp paper.

When a project goes wrong

• Escalation. A dispute first goes to the project managers, then to senior representatives, within short fixed periods.
• Technical expert. For disputes about whether software meets its requirements, the agreement can refer the question to an independent technical expert, whose view is binding or advisory as agreed. This is often quicker and more useful than a lawyer’s argument about code.
• Mediation. For commercial disputes above the relevant value, the Commercial Courts Act requires pre-institution mediation before a suit is filed, unless urgent interim relief is sought.
• Arbitration or courts. Arbitration offers privacy, a chosen tribunal and easier international enforcement; courts may be cheaper for smaller claims. The agreement should choose one, with a seat and language.
• Interim relief. Either side should remain free to seek urgent relief — for instance, an order to hand over code or credentials, or to stop the misuse of confidential information.

We prepare the agreement, change documents and notices. Any dispute that goes to arbitration or court is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it. You can find an advocate through our directory.

An example: an exporter’s order-tracking app

A garment exporter in Okhla wanted an app through which its overseas buyers could see the production stage of each order — cutting, stitching, finishing, quality check, dispatch — with photographs uploaded by floor supervisors. Its first attempt, with an agency engaged on a two-page quotation, had failed in the way described at the top of this page. For the second attempt, it structured the project differently.

It paid a small fixed fee for a four-week discovery phase, at the end of which it owned a requirements document, clickable screens approved by two of its buyers, and a list of integrations with its existing accounting software. The build was then priced as a fixed fee for the first release and time and material, within a monthly cap, for later features. The repository, the store accounts and the cloud project were created in the exporter’s name before development started, and the developer committed code weekly. The acceptance schedule listed twenty-four test scenarios written from the buyers’ point of view, with severity levels and a ten-working-day testing window.

When the exporter asked, halfway through, for the app to work in two additional languages, the change request process produced a price and a two-week extension, which it approved in writing. When a key developer left, the key personnel clause obliged the agency to provide a replacement and a week of overlap at its own cost. The first release went live eleven days late, all of which were attributable to the approved change and the exporter’s own delay in supplying buyer data, so no delay damages were payable and none were claimed. Two years later, when an investor asked for evidence that the company owned its app, the exporter produced the assignment, the list of background components and the open source schedule in an afternoon.

An example: a developer protecting its payment

A four-person development studio in Noida had built an online booking platform for a chain of clinics under a contract that paid most of the fee “on completion”. The client used the platform for three months, raised a stream of new requests, and paid nothing further, saying the project was not complete. The studio had no written requirements to show what completion meant.

For its next contracts, the studio adopted a master agreement with statements of work. Each statement of work attached approved screens and a list of acceptance scenarios. Payments were split into five milestones, each triggered by an objective event, and the acceptance clause provided for deemed acceptance after ten working days without a report of critical or major defects, or on the first use with real customers. Ownership of each release passed to the client on payment for it, with a perpetual licence to the studio’s booking and notifications modules, which were listed as background IP. Invoices carried interest for late payment, and the studio registered as a micro enterprise.

When a later client began using a release with its customers while disputing minor cosmetic issues, the studio pointed to the deemed acceptance clause and the severity table, fixed the cosmetic issues within the warranty, and was paid within the agreed period.

Where software contracts go wrong

• A quotation instead of a contract, with no requirements, acceptance or ownership.
• No written assignment, so the developer owns the code the client paid for.
• Code, domains and store accounts in the developer’s name.
• Payment “on completion” without defining completion.
• No deemed acceptance, so acceptance can be delayed indefinitely.
• No defect classification, so a spelling error can block a payment.
• Changes agreed on messaging groups with no record of price or time.
• Undisclosed copyleft components in proprietary software.
• A warranty that promises bug-free software, or none at all.
• No handover obligation on termination.
• Maintenance assumed but never agreed, leaving the software unsupported after launch.

Our fee and what you get

A software development agreement from us costs ₹4,999 and is ready in 2 – 5 days. We start from your project — what is being built, for whom, by whom, on what platforms, with what data — and draft for your side of the table, whether you are the client or the developer.

Stamp duty, where needed, is extra at actual cost, and we tell you the total before we start. Tax treatment is for your chartered accountant. If a dispute ever reaches an arbitrator or a court, it is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it.