Software development agreement: a clause-by-clause checklist to hold your developer’s contract against

A software development agreement is the contract between you and the people building your software. It should say exactly what will be built, how you will check it, when you pay, who owns the result, what you get back if the project stops, and what happens after launch. Most disputes over custom software come from one of those being left out, not from bad code.

This post is a checklist you can hold a developer’s draft against, clause by clause. For each clause it says what a good version looks like and what should make you stop. It is written for the owner of a small business buying a CRM, an app or a website, not for lawyers. We build custom software ourselves, so read it with that in mind.

The software development contract checklist, in one table

Get the developer’s draft agreement and go down this table. Mark each clause present, weak or missing. Anything missing is a question to ask before you pay the first instalment.

1. The scope document, attached as an annexure

The scope is the most important page of the contract, and it is usually not in the contract at all. It sits in an email thread or a set of call notes. Ask for it as a numbered annexure that the agreement refers to by name: “the Software described in Annexure A”.

A usable scope lists every screen, every field that matters, the rules (who sees what, what happens when a quotation is accepted), the reports, the integrations, and the data that has to come across from your old system. It also says what is not included. “Mobile app not included; the system will work in a phone’s browser” prevents an argument in week six.

If you cannot get a written scope, you cannot get a fixed price, and every other clause in this list becomes weaker. What custom software actually costs explains why scope agreed on a call is the thing that blows up budgets.

2. Milestones, acceptance and payment

Each payment should be tied to something you can open and check, not to the calendar. “30% when the quotation module is accepted” is a milestone. “30% on 15 December” is a date, and you pay it whether or not anything works.

The clause most drafts skip is acceptance: how you decide a milestone is done. A fair version says you test the delivered part against the scope within a fixed number of days, report what fails in writing, and the developer fixes those items before the milestone counts as accepted. It also says silence for that period counts as acceptance, which is reasonable; it stops you holding a payment back for weeks without saying why.

A worked example, with made-up figures: a ₹3,00,000 CRM paid as ₹60,000 on signing, ₹60,000 when the screens are approved, ₹90,000 when the lead and quotation parts are accepted, and ₹90,000 at launch and handover. At no point have you paid much more than what you can see working.

3. Change requests

You will want something that is not in the scope. Everyone does, usually after your staff see the first working build. The contract should say how that is handled: you ask in writing, the developer replies with the cost and the effect on the dates, and nothing is built until you approve.

The clause protects both of you. Without it, the developer either builds your extras free and quietly cuts corners elsewhere, or sends a surprise bill at the end. Also check the reverse: if the developer underestimated something that was in the scope, the agreement should make that their cost, not a change request.

4. Who owns the code

The code does not become yours just because you paid for it. Under the Copyright Act, 1957 a computer programme is a literary work and its author is the first owner. The employer exception covers staff on a contract of service, not an outside firm. We set this out in more detail in our guide to custom software development.

Ownership moves by assignment, and Section 19 of the Act sets traps for a vague one:

• It must be in writing and signed by the assignor.
• If the period is not stated, it is deemed to be five years.
• If the territory is not stated, it is presumed to be India only.
• If the assignee does not exercise the rights within one year, the assignment is deemed to lapse, unless the assignment says otherwise.

That last one is rarely mentioned. So the clause you want assigns to you all rights in the code, designs, database structure and documentation, for the full term of copyright, worldwide, says the assignment does not lapse for non-use, and says it takes effect on final payment. Two honest exceptions are normal: open-source libraries stay under their own licences, and a developer may keep general-purpose tools they wrote before your project, provided you get a permanent, free licence to use them in your software.

5. Source code, repository and accounts handover

Owning the copyright is little use if you cannot get the code. The agreement should list what is handed over at the end, and when:

• The full source code in a repository transferred to your own account, not a zip file of the latest version.
• Database structure, setup notes and every password needed to run it.
• The domain, hosting or cloud account, email-sending service, WhatsApp Business account and payment gateway, all in your business’s name.
• Play Store and App Store listings under your own developer accounts, if there is an app.

Better still, have these accounts opened in your name at the start, with the developer added as a user. Getting a domain back from a developer who registered it in their own name is slow and awkward, and the contract is your only lever.

6. Warranty: the free bug-fix period

There is no legal standard length. What the clause needs is a stated period after launch during which defects are fixed free, a definition of a defect (the software not doing what the scope says), and how quickly a reported defect is looked at. Without the definition, every bug becomes a debate about whether it is really a new feature.

Know what the warranty does not cover: new features, changes in a third-party service such as a payment gateway, and problems caused by someone else editing the code.

7. Data and confidentiality

Your developer will see your customer list, prices and margins. A confidentiality clause, or a separate NDA signed before the first detailed call, should keep them to your project only and require them to be returned or deleted at the end.

If the system holds your customers’ personal data and the developer will host or handle it, there is a second reason to write this down. Section 8(2) of the Digital Personal Data Protection Act, 2023 says a business may involve a data processor to process personal data on its behalf only under a valid contract. Ask your lawyer what that contract needs to say for your case; at minimum, state what data the developer may access, for what purpose, how it is secured and what happens to it when the work ends.

8. Termination: what you get if it ends early

Projects do stop: the developer goes quiet, a key person leaves, or you change direction. A good termination clause lets either side end the agreement with written notice, and says:

• You pay for milestones already accepted, and a fair share of the one in progress.
• You receive everything built so far, the code and the accounts, within a stated number of days.
• The assignment of rights covers the work you have paid for, even though the project did not finish.
• Nothing is held back as leverage over a disputed invoice beyond the disputed amount.

This is the clause most often missing from small contracts, and the one you will most want if things go badly. Another developer can carry on from working code and setup notes. Nobody can carry on from nothing.

9. Support after launch

Software needs patching, backups and small changes for as long as it runs. The agreement, or a separate one offered with it, should state the monthly price of support, what it includes, and that you are free not to take it. A support plan that you must buy, at a price to be decided later, is how a cheap build becomes an expensive one.

What clauses are missing from most small-business software contracts?

In our reading, three: an acceptance process that says how a milestone counts as done, a termination clause that hands over the work built so far, and a handover list naming the accounts, not only the code. The copyright assignment is often present but vague, which under Section 19 can make it last five years and cover India only.

The remaining clauses are the usual ones, and worth a lawyer’s eye: a limit on each side’s liability, governing law and where disputes are heard, how notices are sent, and that the agreement plus its annexures replaces earlier emails and calls.

When this checklist is more than you need

For a small business website at the lower end of the price range, a full agreement with nine negotiated clauses may cost more in time than the project is worth. Even then, insist on three things in writing: a one-page scope, the domain and hosting in your name, and the source files handed over. Our notes on business website development cover what that handover includes.

And if you are subscribing to ready-made software rather than commissioning it, there is no development agreement to negotiate. You accept the vendor’s terms, so check data export and cancellation instead. If you are unsure which path you are on, read buy or build: when off-the-shelf is the right answer first.

How Enkay Technologies handles these clauses

For our own custom CRM development work, the written scope with every screen and rule comes before any payment, with a fixed price and a dated plan. Projects are paid in stages tied to delivery, not to dates. The price does not move unless you change the scope; anything new is quoted separately and you decide. On final payment the repository, source code and every account created for the project are transferred to you, the copyright is assigned in writing, and the first 30 days of fixes after launch are free. A care plan starts at ₹5,000 a month and is optional. We sign an NDA before the scoping call if you want one.

We do not offer legal advice, and you should still have your own lawyer read our agreement. The point of this checklist is that you can hold ours, or anyone’s, against it.

Before you sign a software development agreement

A good software development agreement is mostly plain business sense written down: what is being built, how you will know it is done, what you pay and when, and what is yours at the end, including if it ends early. Go through the draft with the table above, send the developer your list of missing clauses, and see how they reply. A developer who welcomes the questions is usually the one you want. For the wider choice of who to hire, see what Enkay Technologies builds and compare the written scopes you get back, not the prices on the phone.

Frequently asked questions

Keep reading