Browse our curated list of Custom Software Development Companies
A software development contract checklist for India has to cover more than the usual scope, price and deadline, because Indian copyright law doesn’t hand you the code just because you paid for it. Under the Copyright Act, 1957, the person who writes a work is its first owner, and the exception for employers only covers people working under a contract of service[1]. An outside development company isn’t your employee, so the code is theirs until a signed, written assignment says otherwise.
This checklist is for the person signing on the buyer’s side: a founder, an operations or IT head, or a product owner who has picked a partner company and now has its standard agreement sitting in their inbox. We’ve gone clause by clause through what to ask for, what the Indian rules say where they apply, and the gaps we see most often in partner-drafted contracts. It isn’t legal advice, and for a large project you should still have a lawyer read the final version, but you’ll walk into that conversation knowing what to look for.
If you only have a minute
- Put the code assignment in writing and state the duration and territory. If the contract is silent, Section 19 of the Copyright Act treats the assignment as lasting five years and covering India only[1].
- Tie each payment to a written acceptance step, and know that if your partner company is a registered micro or small enterprise, the law expects payment within 45 days of acceptance[2].
- If the software will handle customers’ personal data, the DPDP Act only lets you use a data processor under a valid contract, and you stay responsible for what they do with it[3].
- Keep the code repository, cloud accounts and domains in your company’s name from the first week, so leaving is a decision and not a negotiation.
Why a Software Development Contract Needs More Care in India
Most contract checklists that rank online are written for US, UK or Australian readers, so they skip the Indian statutes that decide who owns the code, how personal data must be handled and when an invoice has to be paid. Three of those rules change what your contract needs to say.
The first is copyright ownership. Section 17 makes the author the first owner, and Section 19 says an assignment is only valid if it’s in writing and signed. The same section asks the assignment to name the work, the rights, the duration and the territory. It also says the assignment lapses if the rights aren’t used within a year (unless the document says otherwise), and that it defaults to five years and India only when those details are missing[1].
Courts have applied those defaults to software. In Pine Labs v Gemalto, decided by a Delhi High Court division bench in August 2011, the software had been built for Indian Oil’s fleet card programme. The master services agreement said the developer “assigns” the copyright, but it never said for how long or where. The court applied the five-year and India-only defaults to that assignment[4]. A buyer who thought they owned the code outright found that they only held it for five years and only within India.
The second rule is about data. If your app or platform collects personal data from Indian users, you’re the data fiduciary under the Digital Personal Data Protection Act, 2023, and the development company is your data processor. The Act lets you engage a processor “only under a valid contract”, and it keeps you responsible for processing done on your behalf, whatever the contract says[3].
The third is payment. Many Indian development firms are registered micro or small enterprises. Under the MSMED Act, 2006, a buyer who pays them more than 45 days after accepting the work owes compound interest at three times the RBI bank rate[2]. That makes your acceptance clause a legal date as well as a project step.
The Software Development Contract Checklist for India
Use this table as a review sheet. Go down the left column with the partner company’s draft open beside it, and mark anything that’s missing or vague.
| Clause | What it should say | Why it matters in India |
|---|---|---|
| Parties and documents | Legal names, registered addresses, GSTINs, and which document wins if the master agreement and a statement of work disagree | Invoices and TDS need the right legal entity, and a clear order of documents stops arguments over which version applies |
| Scope and deliverables | A statement of work listing features, screens, integrations, platforms and what’s excluded, plus the documents you’ll receive | Vague scope is where most disputes start, and the cost of a change request depends on it |
| Ownership of code (IP) | A present assignment of copyright in all deliverables, worldwide, for the full term of copyright, effective as each milestone is paid | Without the duration and territory, Section 19 limits the assignment to five years and India |
| Pre-existing code and libraries | A list of the partner’s own reusable components with a perpetual, royalty-free licence for you, and a list of open-source packages with their licences | Agencies reuse code across clients, so you can’t own all of it, but you need the right to use and change it forever |
| Payment schedule | Milestones with amounts, the acceptance step that triggers each invoice, GST shown separately, and who handles TDS | Paying by acceptance protects you, and the MSMED 45-day rule may apply to your payments |
| Acceptance testing | A test period (for example 7 to 10 working days), written acceptance criteria per milestone, and what counts as a blocking bug | Without criteria, “done” becomes an opinion, and deemed acceptance can start the payment clock |
| Change requests | A written change-request form with cost and time impact, approved before work starts, and the rate card for extra hours | Stops scope creep from turning into a surprise invoice at the end |
| Timeline and delays | Dates per milestone, what happens if either side causes a delay, and any agreed delay credit | Your own late feedback can push dates, so the contract should cover delays on both sides |
| Warranty | A bug-fix period after go-live (commonly 30 to 90 days) at no extra cost, with response times | Gives you time to find problems in real use before the support contract begins |
| Confidentiality | What counts as confidential, how long the duty lasts, and that it covers the partner’s staff and subcontractors | Your business logic and customer lists will sit in their systems |
| Data protection | Processing only on your instructions, security safeguards, breach reporting to you within a set number of hours, and deletion or return of data at the end | The DPDP Act needs a valid contract with your processor and leaves the liability with you |
| People and subcontracting | Named key people, notice before they’re replaced, and no subcontracting without your written consent | Code written by an unapproved freelancer may not be covered by the partner’s assignment to you |
| Termination and exit | Exit for convenience with notice, payment for accepted work only, and a handover of code, credentials and documents within a set number of days | Leaving a project shouldn’t mean losing your code |
| Liability and indemnity | A cap on liability (often the fees paid), excluding IP infringement, confidentiality and data breaches from the cap | If their code infringes someone else’s rights, you shouldn’t carry that cost |
| Disputes and signing | Governing law, an arbitration seat and the number of arbitrators, stamp duty paid, and e-signatures by authorised signatories | An unstamped agreement can’t be relied on as evidence until the duty and penalty are paid |
Fifteen rows sounds like a lot, but a typical partner-company template already deals with confidentiality, liability and disputes in some form. Ownership, acceptance, data protection and exit tend to be the thin ones, so that’s where we’d spend your review time.
Ownership of the Code: Get the Assignment Wording Right
Ask for a present assignment (“hereby assigns”), not a promise to assign later, and make sure it names all four things Section 19 asks for: the work, the rights, the duration and the territory[1]. In practice that means a clause saying the partner company assigns to you, worldwide and for the full term of copyright, all rights in the source code, object code, designs, database structures and documentation it creates for the project.
Two more lines are worth adding. Because Section 19 says an assignment lapses if the rights aren’t exercised within one year “unless otherwise specified in the assignment”, the clause should say plainly that it won’t lapse for non-use[1]. And because the assignment has to specify the consideration, link it to the fees in the payment schedule so nobody can later argue that no price was stated.
It’s fair for the partner company to keep ownership of tools it built before your project, like a login module it uses for every client. There’s no point fighting that. Ask for a list of those components in a schedule, with a perpetual, royalty-free, transferable licence to use and modify them inside your product, so an investor or acquirer doing due diligence later doesn’t find a gap.
Open-source code needs the same list. Most modern apps pull in hundreds of packages, which is normal, but some licences come with obligations to share source code if you distribute the software. A short schedule naming the main packages and their licences, plus a promise from the partner company not to add restrictive licences without asking you, takes an hour to prepare and saves a painful audit later.
One more thing on ownership. If the partner company uses freelancers, it only owns their code if it has its own written assignment from them, so the contract should say the partner company will get those assignments and pass the rights on to you.
Payment Terms, Milestones and the 45-Day Rule
Pay against accepted work, not against time passing. A common structure for a fixed-scope project is a small advance, then three or four milestone payments, each triggered by your written acceptance, with a final slice held until the warranty period ends.
| Milestone ($12,600 example) | Share | Amount | Released when |
|---|---|---|---|
| Signing and kick-off | 10% | $1,260 | Contract signed and project plan shared |
| Design sign-off | 20% | $2,520 | You approve the screens and the clickable prototype in writing |
| Beta build | 30% | $3,780 | Core features work on a test server and pass the agreed test cases |
| Go-live acceptance | 30% | $3,780 | Production launch and no open blocking bugs |
| End of warranty | 10% | $1,260 | 60 days after go-live with all warranty bugs closed |
This split is an illustration rather than a market standard, and plenty of good partner companies ask for 20% to 30% upfront on smaller projects. What matters is that the bulk of the money follows working software, and that each trigger is something you can check rather than “development 50% complete”.
Many buyers never hear about the next rule until a partner company invokes it. If your partner company is a micro or small enterprise registered under the MSMED Act, Section 15 caps the agreed payment period at 45 days from acceptance of the services. Pay later than that and Section 16 makes you liable for compound interest, with monthly rests, at three times the bank rate notified by the RBI[2]. That interest applies even if your contract says something different.
So ask the partner company for its Udyam registration status before you sign, write the acceptance procedure in detail, and make sure your accounts team knows the clock starts at acceptance (or deemed acceptance), not when the invoice reaches finance. If your contract says the deliverable is deemed accepted after ten days of silence, those ten days count against you.
On tax, ask for GST to be shown as a separate line and agree who deducts TDS and under which head. The section numbers moved when the Income-tax Act, 2025 took effect in April 2026, so let your CA confirm the current rate rather than copying an old template.
Acceptance Testing, Warranty and Change Requests
Every milestone should have written acceptance criteria, ideally a list of test cases written together before development starts. Give yourself a fixed testing window, often seven to ten working days, and define a blocking bug (one that stops a user finishing a core task) separately from cosmetic issues that can be fixed later without holding back payment.
The warranty should cover bugs found after go-live for a set period at no cost, with a response time for serious issues. Thirty to ninety days is common. Be clear that a warranty covers defects in what was agreed, not new features, because that line is where many post-launch arguments start.
Change requests need a simple paper trail. Every change, however small, gets a short written request with the extra cost and the effect on the timeline, and work starts only after you approve it in writing (an email is fine if the contract says so). Attach a rate card for extra hours so you aren’t negotiating prices in the middle of a deadline.
Data Protection Terms Under the DPDP Act
Your contract is the “valid contract” that Section 8 of the DPDP Act asks for whenever the partner company will see, store or process personal data[3]. That includes customer records, phone numbers, employee data and even test data copied from production. The same section keeps you, the data fiduciary, responsible for complying with the Act for processing done on your behalf, and asks you to take reasonable security safeguards to prevent a breach, including at your processor.
The penalties are set high on purpose. Failing to keep reasonable security safeguards can attract up to $26.3 million, and failing to tell the Board or affected people about a breach up to $21.1 million[5]. The Rules were notified on 14 November 2025 with an eighteen-month phased timeline for compliance[5], so contracts signed now will still be running when the main duties start applying.
At a minimum, the data clause should say the partner company processes personal data only on your written instructions and uses agreed security measures such as access control, encryption and logging. It should report any breach to you within a fixed number of hours, so you can meet your own reporting duty, and it shouldn’t pass data to subcontractors without your consent. When the work ends, it deletes or returns the data. Ask for test environments to use dummy or masked data wherever possible.
Exit Terms: Termination and Handover
Write the exit plan while everyone still gets along. The contract should let you end the work for convenience with notice (30 days is common), pay only for accepted milestones and approved work in progress, and get a full handover within a fixed number of days.
A good handover clause lists what you receive: the full source code with commit history, build and deployment scripts, database schemas, API keys and environment settings, third-party account details, design files and technical documentation. Ask for a handover call with your new team or in-house developers, a few hours of which can be included at no cost.
The cheapest protection is to create the GitHub or GitLab organisation, the cloud account, the app store accounts and the domain in your company’s name on day one and then give the partner company access. If the relationship ends, you remove their access rather than asking them to transfer anything.
Disputes, Stamp Duty and Signing
Choose an arbitration seat (the city whose courts supervise the arbitration), the number of arbitrators and the language, and pick Indian law if both companies are in India. A sole arbitrator is usually cheaper and faster for mid-sized projects.
Pay the stamp duty. The rate depends on your state. In December 2023 a seven-judge Supreme Court bench held that an unstamped or under-stamped agreement isn’t void, but it can’t be admitted as evidence until the duty and penalty are paid[6]. Most states let you buy e-stamp paper online, and it’s far easier to stamp the agreement at signing than in the middle of a dispute.
Check that the person signing for the partner company is actually authorised, either as a director or under a board resolution. Then keep the signed copy, every statement of work and every approved change request together in one shared folder.
Red Flags in a Partner Company’s Standard Contract
Most partner companies send a template that protects them, which is reasonable as a starting point. These clauses are the ones we’d push back on before signing:
- IP transfers “on full and final payment of all dues” with no milestone-wise transfer, which lets one disputed invoice hold the whole codebase hostage
- An assignment that doesn’t mention duration or territory, or a licence to use the code in place of ownership
- Deemed acceptance after two or three days, or acceptance on delivery rather than after testing
- Liability capped at one month’s fees, with no carve-out for IP infringement or data breaches
- The partner company hosting the code repository and production servers in its own accounts with no handover terms
- A non-solicitation clause that stops you hiring any of their staff for several years, even after the project ends
- No mention of subcontractors, freelancers or where your data will be stored
None of these means the partner company is acting in bad faith. Templates get copied from project to project, and many teams have never had a client ask. A good partner company will usually agree to reasonable changes within a day or two, and how they respond to your markup tells you a lot about how they’ll handle problems later.
UpBusiness Data: What Buyers Ask Before Hiring
We looked at the eight genuine project briefs and enquiries buyers had submitted on UpBusiness by October 2026, leaving out staff and test entries. Seven of the eight were written by the person who makes the final decision, and budgets ranged from $110 to $260 at the small end to $2,600 to $5,300 at the top, with $1,050 to $2,600 the most common band (three briefs). Not one of the eight mentioned code ownership, payment milestones, confidentiality, warranty, handover or change requests anywhere in its goals, deliverables or questions.
That fits what this checklist is for. Buyers think hard about what they want built and what it will cost, and the contract terms usually come up only when the partner company sends its own template. Reading this list before you send the brief means you can ask for these terms in the proposal itself, when they’re easiest to agree.
On the supply side, the 10 approved custom software development companies on UpBusiness report a median minimum project of $2,600 and a median average project of $10,500, and nine of the ten say they’ve handled projects of $26,300 or more. Most are teams of 11 to 200 people, four are based in Noida, and the median company has been in business for eight and a half years. A firm that regularly takes on $10,500 projects will usually have a standard agreement ready, so the checklist above is mainly for reviewing their draft rather than writing your own from scratch. These figures are self-reported on company profiles and the samples are small, so read them as a picture of who’s on the platform rather than a market survey.
Find a Software Development Partner on UpBusiness
A tight contract starts with a clear brief. Our software project brief template helps you write one that gets comparable quotes, and our guide to comparing software development proposals shows how to line those quotes up before you choose. When you’re ready, browse verified custom software development companies or post your project and let matching partner companies come to you, then use this checklist on whichever contract you get.
