Most disputes between Indian SMEs and their software vendors do not start with bad code. They start with a contract that never said who owns the code, what "done" means, or what happens if a milestone slips. If you are about to sign with a development partner, these are the clauses worth getting right before anyone touches a keyboard.
Who actually owns the code once you've paid for it?
Many business owners assume that paying an invoice automatically makes them the owner of the software. Under Indian law, that is not how it works. Copyright in software is governed by the Copyright Act, 1957, which treats computer programs as literary works protected automatically from the moment of creation, with no registration required to hold rights.
The default position under Section 17 of the Act is that the author of a work is its first owner, and an employer only becomes the first owner where the work is created by an employee in the course of employment under a contract of service. That exception is narrow. An independent agency or freelance developer engaged under a contract for services is not an employee, so there is no general "work made for hire" rule that automatically hands software copyright to the paying client. In practice, this means that under a contract of service the employer owns the work, but with an independent contractor the copyright stays with the developer unless it is explicitly assigned.
The fix is simple but non-negotiable: your contract needs a written IP assignment clause, not a vague reference to "deliverables belonging to the client". If your business depends on owning the copyright in work created by an agency or contractor, the engagement contract should state ownership expressly, in writing, signed by both parties, because the statutory default will not do it for you. Ask specifically about third-party libraries, open-source components and any pre-existing code the vendor reuses across clients — these are usually licensed, not assigned, and should be listed separately.
Nail the scope before any coding starts
A one-page quote is not a scope of work. A workable Statement of Work should cover: the features included, explicitly excluded items (so "we'll add that later" doesn't become a free add-on dispute), the technology stack, integration points with your existing systems, and who provides content, data and third-party accounts. Attach wireframes or a feature list as a schedule to the main agreement, not just an email thread, since emails are easy to lose track of once a project runs past its original timeline.
Build in a formal change request process from day one. Define how a change is raised, who approves cost and timeline impact, and how it is recorded. Without this, scope creep becomes invisible until the invoice arrives, and by then neither side agrees on what was originally promised.
Payment terms: protect your cash flow and the vendor's
Tie payments to milestones you can actually verify — a signed-off design, a working staging build, UAT completion — rather than purely to dates on a calendar. This gives you leverage to withhold payment if a milestone genuinely isn't met, and gives the vendor certainty about when cash arrives.
If your vendor is a registered micro or small enterprise, the Micro, Small and Medium Enterprises Development Act, 2006 works in their favour, and you should know the rule applies regardless of what your contract says. Section 15 requires a buyer to pay a registered micro or small enterprise supplier within the period agreed in writing, which cannot exceed 45 days from acceptance or deemed acceptance of the goods or services, and if no period is agreed, payment is due within 15 days. Section 16 overrides anything the contract says and makes compound interest, calculated at three times the Reserve Bank of India's bank rate, payable on delayed amounts. It is worth checking your vendor's Udyam status, since the Union Budget 2025 revised MSME classification limits, increasing investment thresholds by 2.5 times and doubling turnover limits, so a vendor you assumed was too large to qualify as a small enterprise may still be covered.
Don't forget GST. Software and app development in India is taxed at a standard 18% GST rate under SAC code 998314, covering custom development, websites and app builds. Confirm whether quoted prices are GST-inclusive, and get the vendor's GSTIN on the invoice if you plan to claim input tax credit.
Make acceptance testing a contract clause, not an afterthought
User Acceptance Testing (UAT) is where "it works on the developer's laptop" meets "it works for my business". Your contract should spell out: who writes the test cases (ideally jointly), how long you have to test each milestone, what counts as a blocking defect versus a minor one, and what happens if you simply don't respond — many contracts include a "deemed acceptance" clause that treats silence past a set number of days as sign-off, which protects the vendor from indefinite delay but can also trap a busy client who hasn't actually reviewed the work.
Agree a bug-severity scale upfront (critical, major, minor, cosmetic) and a response-time commitment for each during the warranty period. This avoids arguments later about whether a slow checkout page is a "critical" issue that blocks final payment or a minor one to be fixed in a later release.
Handover: what "done" should actually give you
Handover is where many Indian SMEs discover too late that they don't control their own software. A proper handover should include: full source code in a repository you own (not just the vendor's), database schemas and migration scripts, admin credentials for hosting, domain and third-party services, environment configuration files, and technical documentation covering architecture and deployment steps. Ask for this to be transferred progressively during the project, not bundled into a single folder at the very end when leverage has shifted entirely to the vendor.
Build a short warranty period (commonly 30 to 90 days) into the contract covering free fixes for defects traceable to the original build, distinct from any ongoing maintenance retainer, which should be a separate commercial arrangement with its own SLA.
Signing it: does the contract need to be on paper?
Indian contract law does not require a development agreement to be signed in wet ink. Under the Information Technology Act, 2000, particularly Section 10A, an electronic contract is valid and enforceable, and the main requirement is that it meets the usual conditions of the Indian Contract Act, 1872. A clearly worded PDF signed digitally or via e-signature, with both parties' acceptance recorded, is legally sound. What matters far more than the medium is that the scope, IP, payment and acceptance terms are written down and agreed before work begins — verbal understandings and WhatsApp confirmations are hard to enforce if things go wrong.
Conclusion
A good contract with a software partner is not about distrust; it is about making sure both sides have the same understanding of scope, ownership, money and what a finished product looks like. Getting the IP assignment, payment terms, UAT process and handover checklist right at the start costs an afternoon of careful drafting and saves months of disputes later. If you are scoping a web, mobile or custom software project and want a second opinion on the technical and contractual side, devtechnician.com is one place to start the conversation.
Sources
- Section 15 of MSMED Act: 45-Day Payment Rule Explained
- Section 16 of MSME Act – Understanding Provisions
- Copyright Law in India: A Practical Guide for Creators
- Software Agreements in India: How to Comply With the Indian Copyright Act
- Copyright Ownership of Source Code in India
- MSME Registration Guide - Udyam Registration Process Explained
- GST on Software Services: SAC 9983, HSN Code and Rate
- Validity Of Electronic Contracts In India - Legal 500
