# Unpaid freelance developer vs client: who owns the source code **TL;DR:** Under the Copyright Act 1957, the freelance developer who wrote the code is the first owner of copyright in it, not the client, unless there is a written and signed assignment. An invoice, a WhatsApp message, or "we hired you for this" does not transfer ownership. If the client has not paid and there is no valid assignment, you can usually refuse to hand over the repository, but taking down a live deployment or disabling access the client already has crosses into IT Act territory and needs care. The stronger move is usually a legal notice, a Section 138 complaint if a cheque bounced, and if you are Udyam registered, the MSME Samadhaan portal, which most freelancers never use. --- ## On this page - [The question everyone gets backwards](#the-question-everyone-gets-backwards) - [Section 17: who owns the code by default](#section-17-who-owns-the-code-by-default) - [Section 19: what actually counts as an assignment](#section-19-what-actually-counts-as-an-assignment) - [Employee versus freelancer under section 17](#employee-versus-freelancer-under-section-17) - [What you can do when the client stops paying](#what-you-can-do-when-the-client-stops-paying) - [Where self help turns into an offence under the it act](#where-self-help-turns-into-an-offence-under-the-it-act) - [What people actually reported doing](#what-people-actually-reported-doing) - [What your contract should say instead](#what-your-contract-should-say-instead) - [Escrow and milestone structures that prevent this fight](#escrow-and-milestone-structures-that-prevent-this-fight) - [Recovering the money: the legal notice](#recovering-the-money-the-legal-notice) - [If a cheque bounced: section 138 and order 37](#if-a-cheque-bounced-section-138-and-order-37) - [The msme samadhaan route: the most underused remedy](#the-msme-samadhaan-route-the-most-underused-remedy) - [The consumer forum question](#the-consumer-forum-question) - [GST invoices and TDS as proof of the engagement](#gst-invoices-and-tds-as-proof-of-the-engagement) - [Getting the underlying question right before you act](#getting-the-underlying-question-right-before-you-act) - [Frequently asked questions](#frequently-asked-questions) --- ## The question everyone gets backwards A freelance developer builds a product for months. The client pays the first two milestones, gets comfortable, and then the payments slow down and stop. The developer is sitting on a working repository, admin access to a live deployment, and an unpaid invoice that keeps growing. The instinct on both sides is the same: whoever paid for the work owns it. That instinct is wrong under Indian copyright law, and getting this wrong is expensive on both sides. It is the freelance mirror image of an employee who resigns and then finds their old employer trying to claim rights it never actually secured, covered in [joining a competitor after resignation](/blog/joining-competitor-after-resignation): both fights turn on what was actually agreed in writing, not on who feels entitled to the outcome. The client who assumes payment equals ownership can end up distributing software it never actually acquired rights to. The developer who assumes non-payment means "I still own everything, so I can do whatever I want with the deployment" can walk into a criminal complaint under the IT Act. The actual rule sits in two provisions of the Copyright Act 1957: Section 17, which decides who the first owner is, and Section 19, which decides what it takes to move ownership from that first owner to someone else. Everything else in this dispute, including the leverage question and the money recovery question, sits downstream of those two sections. --- ## Section 17: who owns the code by default Section 17 of the [Copyright Act 1957](https://indiankanoon.org/doc/1404402/) sets out who the "first owner" of copyright is for different categories of work. The general rule in the opening part of the section is that the author of a work is the first owner of copyright in it. For software, the author is the person who wrote the code. Section 17 then carves out specific exceptions. The one that matters here is the commissioned work exception, which covers works like photographs, paintings, portraits, engravings, and cinematograph films made for valuable consideration at the instance of another person. Where that exception applies, the person who commissioned the work is the first owner, in the absence of any agreement to the contrary. The commissioned work exception in Section 17 is drafted around specific categories of work. It does not list computer programs among them. This is the point most people miss in a freelance dispute. Software written by an independent contractor does not automatically fall into a "commissioned work" bucket the way a commissioned photograph does. The default position for a computer program written by a freelance developer, absent a contract that says otherwise, is that the developer who wrote it is the first owner of copyright in it. That is a stronger position for the developer than most clients, and honestly most developers, assume going in. A client who says "we paid you to build this, so it is ours" is describing a commercial expectation, not the legal default. The legal default follows authorship unless a contract or a specific statutory exception moves it. None of this means the client has no rights at all. A client who paid for work and received deliverables typically has an implied license to use what was delivered and paid for, at least to the extent the parties' conduct supports that inference. But an implied license to use delivered code is a very different thing from owning the copyright in it, being able to modify it freely, resell it, or license it to someone else. Ownership is the stronger right, and ownership needs an assignment. --- ## Section 19: what actually counts as an assignment Section 19 of the Copyright Act 1957 sets out the mode of assignment, and it is deliberately strict. No assignment of copyright in any work is valid unless it is in writing and signed by the assignor, meaning the person giving up the right, or by that person's duly authorised agent. Section 19 goes further than "put it in writing." A valid assignment has to identify the work being assigned, specify the rights being assigned, and specify the duration and territorial extent of the assignment. Where the assignment is silent on duration, the Act treats it as five years from the date of assignment. Where it is silent on territorial extent, it is presumed to extend only within India. Apply that to the ordinary freelance dispute. An invoice that says "development services for Project X, Rs 2,00,000" is not an assignment. A WhatsApp message that says "we hired you to build this for us" is not an assignment. A purchase order, a Slack thread confirming scope, an email thanking the developer for "your work on our platform," none of these satisfy Section 19. They may be excellent evidence that an engagement existed and that money is owed for it. They do nothing to move copyright ownership from the developer to the client. What does satisfy Section 19 is a signed instrument, usually a clause inside the master service agreement or a standalone IP assignment deed, that identifies the software, states plainly that the developer assigns all rights, title, and interest including copyright to the client, and is signed by the developer. Many freelance contracts in India actually contain this clause and satisfy it. The disputes that end up in a legal grey zone are almost always the ones where there was no written contract at all, or where the contract addressed payment and scope but never touched IP assignment. --- ## Employee versus freelancer under section 17 Section 17(c) is the provision people confuse with the freelancer's position, and the confusion causes real damage in negotiations. Under Section 17(c), where a work is made by an author in the course of their employment under a contract of service, the employer is the first owner of copyright in that work, in the absence of any agreement to the contrary. The operative phrase is "contract of service," which is the legal test for an employment relationship, as opposed to a "contract for service," which is the legal test for an independent contractor relationship. Courts look at control over how and when the work is done, whether the person is on payroll, whether they work exclusively for one principal, whether they use their own tools, and similar factors, to decide which side of that line a given arrangement falls on. A freelance developer working project to project, invoicing per milestone, using their own laptop and tools, working for multiple clients at once, and not receiving PF or ESI contributions is almost always on the contractor side of that line, not the employee side. That means Section 17(c) does not apply to them by default. The employer-owns-it-automatically rule that a salaried in-house developer benefits their employer from is not the rule that governs an independent freelancer. This is exactly why Section 19's written assignment requirement matters so much for freelance work specifically. Without it, the client gets nothing automatic. With an employee, the client gets automatic ownership under Section 17(c) and does not need a Section 19 assignment at all for works made in the course of that employment. This distinction is worth spelling out to a client who pushes back with "but we hired you." Hiring someone as staff and hiring someone as a freelancer are two different legal relationships that produce two different default ownership outcomes, and the label the parties use in casual conversation does not decide which one applies. What decides it is the underlying relationship and, if a written contract exists, what that contract actually says about IP. --- ## What you can do when the client stops paying Once you have established that you, the developer, are very likely the copyright owner in the absence of a written assignment, the practical question becomes what you can lawfully do about the money you are owed. **Refusing to hand over the repository.** If you have not delivered the final source code and the client has not paid for it, you are generally within your rights to withhold delivery until payment, the same way any service provider can withhold an undelivered product pending payment. This is the cleanest form of leverage because it does not touch anything the client already has or already controls. **Refusing to grant further access.** If access to a private repository, a staging environment, or design files has not yet been granted, you can decline to grant it. Declining to give something you have not yet given is different from taking away something the client already has. **Revoking access you already granted.** This is where it gets contested. If you already added the client, or the client's other developer, as a collaborator on a GitHub repository, and you remove that access because of non-payment, you are within your rights as the account owner managing your own repository. This is closer to withdrawing a licence than to an intrusion, and it typically does not implicate the IT Act, because you are acting on infrastructure you control and own, not accessing something that belongs to someone else. **Taking down or disabling a live production deployment.** This is the highest risk move, and it is the one that most often escalates a payment dispute into a criminal complaint. If the application is already live, serving the client's actual customers, and you deliberately disable it, delete data, change credentials to lock the client out of a system they were using, or otherwise interfere with a service that was operational and in the client's possession, you are no longer just withholding your own undelivered work. You are actively interfering with a system, and depending on how that system's ownership and control were structured, that can look very different from a copyright dispute and much more like unauthorised access or damage to a computer system. The line that actually matters in Indian law is possession and control, not ownership of the underlying code. Copyright ownership answers who can reproduce, modify, and license the software. It does not automatically answer who is entitled to access a specific server, account, or production environment at a specific point in time, especially once that access has already been granted and relied upon. --- ## Where self help turns into an offence under the it act Section 43 of the [Information Technology Act 2000](https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef38b787c374ff.pdf) creates civil liability for a person who, without permission of the owner or person in charge of a computer, computer system, or computer network, accesses or secures access to it, downloads or copies data from it, introduces a virus, damages it, disrupts it, or denies access to a person authorised to access it. Compensation under Section 43 can be claimed by the person affected. Section 66 criminalises the same conduct when it is done dishonestly or fraudulently, with punishment of imprisonment up to three years, a fine up to five lakh rupees, or both. The offence turns on state of mind, dishonest or fraudulent intent, not on whether the underlying dispute over payment is genuine. If a client threatens to file a [cyber crime complaint](/blog/cyber-crime-complaint-india) against you, take it seriously enough to get advice on your specific facts rather than dismissing it, and equally do not assume the threat is automatically valid just because it was made. Here is the part that is genuinely uncomfortable for a developer who feels, correctly, that they are owed money. Once a client is "in charge of" a computer system, meaning they are the operator running it, have paid for the hosting, or the system has gone live for their customers, disabling or denying that system to them without their authorisation can fall within Section 43, even if you are the one who originally built and deployed it, and even if you have not been paid. The client who is currently operating the system does not stop being "in charge of" it just because a payment dispute exists between you. This does not mean you have no leverage. It means the safe leverage is withholding what you have not yet handed over, not reaching into something the client is currently operating and disabling it. If you genuinely never granted the client any access, never handed over admin credentials, and the entire application still sits on infrastructure you personally control and have not shared, then declining to hand it over is a straightforward exercise of your ownership. The risk rises sharply the moment the client has already been operating the system, has customers relying on it, and you take an active step to interrupt that. Be precise with a client who threatens you with the IT Act as a scare tactic too. Simply refusing to send files you built and never delivered is not unauthorised access to anything, because there was never any authorised access for the client to lose. The offence requires interference with a system the other side already has legitimate control over. Read the specific facts carefully, ideally with a lawyer, before either side leans on the IT Act as a threat. --- ## What people actually reported doing Freelancers posting in community forums about this exact scenario, an extended engagement that runs many months before payments stop, tend to describe the same arc. Work starts on informal terms, sometimes no written contract at all, or a scope document that never mentions IP. Payments come on time for the first few milestones, then slow, then a final large milestone or two go unpaid while the client keeps asking for more work "before we settle up." The advice that repeats across these threads generally converges on a few points. First, stop delivering further work the moment an invoice goes unpaid past its due date, because continuing to work for free only grows the amount owed and weakens the argument that you treated the contract as still alive on the old terms. Second, do not touch a live production system that the client is already operating and that other people depend on, because the legal risk of that move usually outweighs whatever short-term pressure it creates. Third, a firm, professional written demand for payment, sent by email or through a lawyer, does more real work than a dramatic gesture, because it creates a paper trail that matters later in front of a forum, a court, or an MSME facilitation council. Fourth, freelancers who had GST registration, signed invoices, or even basic email confirmations of scope and price had a much easier time being taken seriously by whichever forum they eventually approached than freelancers who had worked entirely on verbal understanding. The common regret voiced in these threads is almost always the same: not having gotten a signed contract with a clear payment schedule and an explicit IP assignment clause tied to payment, before the first line of code was written. That single document would have resolved both the ownership question and given the developer a much cleaner legal claim for the unpaid amount. Where no such contract exists, a [structured obligation register built from the email trail](/blog/contract-obligation-register-from-email) is often the closest thing a freelancer has to reconstruct what was actually promised. Freelancers early in their career, without an established network of repeat clients to fall back on, are usually the ones most exposed to this pattern, since they are also the least likely to push back on an informal engagement. The same lack-of-connections problem, and the same discipline of building a track record from nothing, shows up for [law students trying to land an internship](/blog/law-student-internship-without-connections). --- ## What your contract should say instead The dispute above is preventable with one clause that most freelance contracts in India either omit entirely or word too loosely. The clause needs to do two things: state clearly when copyright transfers, and tie that transfer to payment rather than to delivery or to the signing of the contract itself. A workable structure looks like this. The developer retains all copyright in the work until the corresponding invoice for that milestone is paid in full. On receipt of full payment for a given milestone, copyright in the deliverables covered by that milestone automatically assigns to the client, in writing, as evidenced by the signed agreement itself, satisfying Section 19's writing and signature requirement at the outset rather than needing a fresh signed document at every milestone. Until payment clears, the client receives, at most, a licence to review and test the work internally, not a right to deploy it commercially or to modify and resell it. This is usually called a "payment triggers assignment" clause, and it solves the practical problem cleanly. It gives the developer clear, contractually documented leverage during a dispute, because ownership has not moved and both sides signed a document that says so. It gives the client certainty about exactly when they will own what they are paying for, milestone by milestone, rather than a single all-or-nothing transfer at project end that leaves them exposed if the project stalls midway. | What your contract says | Who owns the code | What you can do | |---|---|---| | No written contract at all | Developer, by default under Section 17 | Withhold undelivered work; send legal notice for money owed | | Contract covers scope and price, silent on IP | Developer, because Section 19 needs a written, signed assignment | Withhold undelivered work; client has at most an implied licence to use what was paid for | | Contract says "all work product belongs to client" but assignment is unsigned or undated | Ambiguous; depends on whether Section 19's formalities are actually met | Get the assignment properly executed before disputing; do not assume either side automatically wins | | Contract has a payment-triggers-assignment clause, milestones unpaid | Developer, for the unpaid milestones specifically | Withhold deliverables for unpaid milestones; paid milestones already validly assigned | | Contract has an unconditional assignment on signing, regardless of payment | Client, from the date of signing | Developer has no ownership leverage; must recover money through legal notice and civil or MSME remedies only | --- ## Escrow and milestone structures that prevent this fight Beyond the assignment clause itself, the structural fix is to break the payment schedule into small, code delivered milestones rather than a large lump sum at project completion. A four or five month project split into two payments front loads all the client's leverage and all the developer's risk onto the very end of the engagement, which is exactly when a client under budget pressure is most tempted to slow walk payment. Milestone billing every two to four weeks, tied to a specific, testable deliverable, keeps the amount at risk on either side small at any given time. If a client stops paying at milestone six of twelve, the developer has lost roughly two to four weeks of unpaid work rather than four months of it, and the assignment clause means only the unpaid milestone's code stays with the developer, not the entire codebase built to that point. Escrow services, where a third party holds the agreed fee and releases it against milestone sign off, are more common in cross-border freelance platforms like Upwork than in direct India-to-India engagements, but the same logic can be replicated with a simple written milestone schedule and an advance retainer covering at least the first milestone before any work starts. An advance retainer of twenty to thirty percent of total project value, non-refundable once work begins, is a reasonable, common Indian market practice and gives the developer some recovery even in a worst case where the client disappears entirely after the advance. --- ## Recovering the money: the legal notice Once payment has genuinely stopped, the first formal step, regardless of which recovery route you eventually pursue, is a written legal notice. A [legal notice](/blog/how-to-draft-legal-notice) sets out the facts of the engagement, the amount outstanding, the due date that has passed, and a deadline, usually fifteen to thirty days, to make payment before you pursue further legal remedies. The notice does real work beyond signalling seriousness. It creates a dated record that you formally demanded payment, which matters later whether you end up filing a civil suit, an MSME Samadhaan complaint, or a criminal complaint over a bounced cheque. It also gives the client a chance to respond, and how they respond, silence, a dispute over quality, or an admission with a promise to pay, shapes your next move. If you are the one receiving such a notice as the client, the same discipline applies: read the guidance on how to [reply to a legal notice](/blog/reply-to-legal-notice-india) properly rather than ignoring it, since silence is often read against the recipient later. Send the notice by a method that proves delivery, registered post with acknowledgment due, or email if your contract designates email as a valid mode of notice. Keep every invoice, every project management thread, every commit log timestamp, and every payment confirmation you have. These become the evidentiary backbone of whichever forum you approach next, and the earlier you start gathering them the better; the general guidance on [preserving evidence before calling a lawyer](/blog/preserve-evidence-before-calling-lawyer) applies just as much to a payment dispute as it does to any other legal matter. If the client is a company and its in-house legal team gets involved in the back-and-forth, keep in mind that their internal advice to the business is very likely not privileged under Indian law, unlike advice from an outside firm; [in-house counsel privilege in India](/blog/in-house-counsel-privilege-india) explains why that gap exists and how it can affect what surfaces later if the dispute escalates. --- ## If a cheque bounced: section 138 and order 37 If the client paid you with a cheque and it bounced, you have a separate and often faster lever available: Section 138 of the Negotiable Instruments Act 1881. Section 138 makes it an offence to issue a cheque that is returned unpaid for insufficient funds or because the amount exceeds an arrangement with the bank, where that cheque was issued to discharge a legally enforceable debt. The procedure has strict timelines. You must present the cheque to the bank within three months of its date. Once it is dishonoured, you must send a written demand notice to the drawer within thirty days of receiving the bank's dishonour memo. The drawer then has fifteen days from receipt of that notice to make payment. Only if payment is not made within that fifteen day window can you file a criminal complaint, and that complaint must be filed within thirty days after the fifteen day period expires. The [full mechanics of a Section 138 cheque bounce complaint](/blog/cheque-bounce-section-138-ni-act) are covered in detail elsewhere on this site if you need the step by step filing process. Alongside the criminal complaint, you can also file a civil recovery suit for the same amount, and a bounced cheque is a strong candidate for a [summary suit under Order 37 of the CPC](/blog/cpc-civil-procedure-basics), because a cheque is a bill of exchange under the Negotiable Instruments Act and falls within the categories of claims Order 37 covers. A summary suit is faster than an ordinary civil suit because the defendant does not get an automatic right to contest the claim on the merits; they must first apply for leave to defend and satisfy the court there is a real, triable issue, failing which judgment can be entered against them quickly. The two proceedings, criminal under Section 138 and civil under Order 37, can run in parallel because they serve different purposes, punishment in one case, recovery of money in the other. | Recovery route | Trigger | Typical timeline pressure | What you get | |---|---|---|---| | Legal notice | Any unpaid invoice | 15 to 30 day response window | Formal demand on record; often prompts settlement | | Section 138 NI Act complaint | Cheque issued and dishonoured | Present within 3 months; notice within 30 days of dishonour; 15 days to pay; complaint within 30 days after that | Criminal prosecution, strong settlement pressure | | Order 37 CPC summary suit | Written debt instrument, including a bounced cheque | Faster than ordinary civil suit if defendant cannot show a triable defence | Money decree, potentially quicker than a regular suit | | MSME Samadhaan | Udyam registered freelancer, buyer delayed beyond 45 days | Council must generally decide within 90 days of admitting reference | Payment plus compound interest at 3x RBI bank rate | | Consumer forum | Rarely applies; freelancer is usually the service provider, not the consumer | N/A in most freelance-vs-client disputes | Not the right forum in the typical case | --- ## The msme samadhaan route: the most underused remedy This is the remedy most freelance developers in India do not know exists, and it is often stronger than a civil suit for exactly this kind of dispute. The Micro, Small and Medium Enterprises Development Act 2006, commonly the MSMED Act, gives micro and small enterprises a statutory right to be paid within a fixed window, with compound interest running automatically if the buyer misses it. Section 15 of the MSMED Act requires the buyer to pay on the date agreed in writing between the parties, and that agreed date cannot exceed forty five days from the day the buyer accepts the goods or services. If there is no written agreement on the payment date at all, the statutory default is fifteen days from acceptance. This applies squarely to a freelance developer supplying software development services to a client, provided the developer is registered as a micro or small enterprise on the Udyam portal. Section 16 is where this remedy gets teeth. Once the buyer misses that deadline, the buyer becomes liable to pay compound interest, compounded monthly, at three times the bank rate notified by the Reserve Bank of India. That interest accrues automatically under the statute; it does not need to be separately negotiated or written into the contract. It is also, notably, not allowed as a deductible business expense for the buyer under the Income Tax Act, which raises the real cost of delay for the client considerably. To use this remedy, you file a complaint on the [MSME Samadhaan portal](https://samadhaan.msme.gov.in/) (samadhaan.msme.gov.in, reviewed 19 August 2026), which routes it to the Micro and Small Enterprise Facilitation Council in the relevant state. You need a valid Udyam registration as the supplier, which is free and takes a few minutes on the Udyam registration portal if you have not already done it, along with proof of the engagement, invoices, and the amount outstanding. The council examines the reference and, unlike a civil court, is empowered to direct payment along with the statutory interest, and can also refer the matter for conciliation or arbitration under the Act if it is not resolved directly. For an unpaid freelance developer, the practical advantage over a straight civil suit is threefold. The forum is purpose built for exactly this kind of payment delay, the interest calculation is aggressive enough to bring a client to the table quickly, and it does not require litigating the underlying copyright or IP question at all, since it is purely a money claim for services rendered. The catch is the Udyam registration requirement; if you never registered as a micro enterprise, this route is closed to you for that engagement, which is itself a strong reason to register before, not after, the next dispute arises. --- ## The consumer forum question Freelance developers sometimes ask whether they can approach a consumer forum against a non paying client, or whether a client who received defective code can approach one against the developer. In the typical freelance-versus-client dispute, neither direction usually fits. The [Consumer Protection Act 2019](/blog/consumer-protection-act-2019) protects a "consumer," someone who buys goods or hires services for consideration and does not use them for a commercial purpose. A business client who commissions software for its own commercial operations is generally engaging the developer's services for a commercial purpose, which can take the client outside the Act's definition of consumer in many fact patterns, particularly where the client is itself a company running a for profit product built on that software. Equally, the developer providing the service is not the "consumer" in this relationship at all; the developer is the service provider, so a developer cannot use a consumer forum to recover unpaid fees, that is not what the forum is for. There are edge cases where a consumer forum genuinely applies, most commonly where an individual hires a developer for a personal, non commercial project and the developer delivers defective or non functional work. In that narrow situation the individual client could, in principle, approach a district consumer commission and could even use the [e-Daakhil portal](/blog/file-consumer-complaint-edaakhil) to file that complaint online. But for the common scenario in this article, a business client engaging a freelancer to build a commercial product, the consumer forum is generally not the right route for either side, and time spent pursuing it is usually better spent on a civil suit or the MSME Samadhaan complaint. --- ## GST invoices and TDS as proof of the engagement Every invoice you raised, and every TDS deduction the client made, is not just an accounting record. It is documentary proof of the engagement itself, and that proof matters enormously once a dispute over payment or ownership goes to any forum. If you are GST registered and raised tax invoices for each milestone, those invoices establish the dates, amounts, description of services, and the client's GSTIN, all of which corroborate that a genuine commercial engagement existed on the terms you describe. A [GST](/blog/gst-2-0) invoice trail also makes it much harder for a client to later claim the relationship was informal, undocumented, or that no specific amount was actually agreed. TDS works in your favour from the other direction. If the client deducted tax at source on your invoices, typically under Section 194J for professional or technical services, that deduction shows up in your Form 26AS and is effectively an admission by the client, made to the Income Tax Department, that they engaged you and owed you the corresponding gross amount. A client who deducted TDS on an invoice and then disputes that any payment is owed at all has to explain why they told the tax department otherwise. This kind of documentary trail, invoices, TDS certificates, Form 26AS entries, and bank statements showing partial payments, is exactly the evidence a Micro and Small Enterprise Facilitation Council or a civil court will ask for, and freelancers who kept clean records consistently have an easier and faster path through whichever forum they end up using. If your engagement involved signed documents, email confirmations, or scanned agreements, keep those too. [Electronic records, including emails and signed PDFs, are admissible as evidence](/blog/bsa-section-63-electronic-evidence) under Indian law provided the procedural certificate requirements are met, and a clear paper trail across invoices, contracts, and correspondence is what turns a "he said, she said" payment dispute into a documented claim a facilitation council or a court can act on quickly. If the matter ends up in a civil suit, be mindful of the limitation period for filing too; see the discussion of [limitation under the CPC](/blog/written-statement-limitation-cpc) for how that clock runs on a money claim. --- ## Getting the underlying question right before you act Before sending a legal notice, filing a Samadhaan complaint, or deciding whether you can lock a client out of a deployment, get the ownership question settled first, because it changes your leverage and your risk on every subsequent step. If your contract is genuinely silent on assignment, you are very likely still the copyright owner, and that is a fact worth stating plainly and confidently in your legal notice, not hedging around. If there is a signed clause you are not sure covers your situation, get it read properly rather than guessing. Tools like Niyam, an Indian legal research AI, can help you check whether a precedent you are relying on for the Section 17 or Section 19 position is [still good law](/blog/good-law-checking) before you build an argument on it, since case law on software as a "commissioned work" under the Copyright Act is not as heavily litigated in India as contract disputes generally, and getting the citation right matters more when the underlying authority is thin. If you are drafting the payment triggers assignment clause described above, the general guidance on [AI assisted contract drafting](/blog/ai-contract-drafting) covers where that kind of tool genuinely speeds up first drafts and where a human review still has to catch the details. Do not let the emotional pull of "I built this, I should be able to shut it down" carry you into a decision that trades a strong civil and statutory position for criminal exposure under the IT Act. The developer who withholds undelivered work, sends a clean legal notice, and files a Samadhaan complaint if Udyam registered, is in a far stronger position four months later than the developer who disabled a live client system on day one of the dispute. --- ## Frequently asked questions ### If I never signed a contract, do I still own the code I wrote? Generally yes. Under Section 17 of the Copyright Act 1957, the author of a work is its first owner by default, and computer programs written by an independent freelancer do not fall within the specific commissioned work exception in that section. Ownership only moves to the client through a written, signed assignment under Section 19, so no contract at all usually means you remain the owner. ### The client says an invoice or email proves they own the code. Is that true? No. Section 19 requires an assignment of copyright to be in writing and signed by the person giving up the rights, and it must identify the work and specify what rights are being assigned. An invoice, a purchase order, or an email confirming scope and price does none of that. They are evidence a transaction happened, not an assignment of copyright. ### Can I delete the client's production deployment if they stop paying? Be very careful here. If the client is already operating the deployment and other people rely on it, disabling it can expose you to civil liability under Section 43 of the IT Act 2000, and criminal liability under Section 66 if done with dishonest intent, because the client is "in charge of" that system even though you built it and have not been paid. Withholding work you have not yet delivered is much safer than interfering with something the client already controls. ### What is the fastest way to recover unpaid freelance fees in India? There is no single fastest route; it depends on your facts. A firm legal notice is always the first step. If you are Udyam registered as a micro or small enterprise, the MSME Samadhaan portal is often the strongest option because it comes with automatic compound interest at three times the RBI bank rate and does not require litigating the IP question at all. If a cheque bounced, Section 138 of the NI Act adds real criminal pressure alongside a civil claim. ### What is the MSME Samadhaan portal and who can use it? It is the government's delayed payment monitoring portal under the MSMED Act 2006, where a Udyam registered micro or small enterprise can file a reference against a buyer who missed the statutory 45 day (or contractually agreed) payment deadline. The relevant state's Micro and Small Enterprise Facilitation Council examines the reference and can direct payment with compound interest. ### Do I need Udyam registration before I can use the Samadhaan portal for a past engagement? You generally need a valid Udyam registration to file a Samadhaan reference. If you were not registered during the engagement, register now before filing; the remedy is about your current status as a registered micro or small enterprise pursuing a payment claim, not about being registered at the exact moment work was performed. Confirm the current procedural requirement with a professional before filing, since portal practice can change. ### Can I file both a criminal complaint under Section 138 and a civil recovery suit for the same bounced cheque? Yes. Section 138 proceedings are criminal and aimed at punishing the dishonour, while a civil suit, commonly a summary suit under Order 37 CPC, is aimed at recovering the money itself with interest. Indian courts allow both to proceed in parallel because they address different objectives. ### Is a freelance developer a "consumer" who can sue a non paying client in a consumer forum? No, generally not. The Consumer Protection Act 2019 protects consumers who purchase goods or services, not the service provider. A freelance developer providing services to a client cannot typically use a consumer forum to recover unpaid fees; that forum is not designed for the person supplying the service. ### What should a payment triggers assignment clause actually say? It should state that the developer retains copyright until the corresponding invoice is paid in full, that copyright automatically assigns to the client on receipt of full payment for that specific milestone, and that until payment, the client holds only a limited licence to review and test the work, not to deploy or commercialise it. This satisfies Section 19's writing and signature requirement at the outset and gives both sides clarity. ### Does GST registration or TDS deduction actually help prove my case? Yes, substantially. GST invoices establish dates, amounts, and the description of the engagement. TDS deducted by the client, typically under Section 194J, shows up in your Form 26AS and functions as an admission by the client to the tax department that they engaged you for the corresponding gross value. Both are strong documentary evidence in front of a facilitation council or a court. ### How much interest can I actually claim through MSME Samadhaan? Section 16 of the MSMED Act entitles a registered micro or small enterprise to compound interest, compounded monthly, at three times the bank rate notified by the Reserve Bank of India, running from the date payment became overdue. This interest is also not deductible as a business expense for the buyer under the Income Tax Act, which increases the practical pressure on the client to settle. ### If the client already has admin access to the deployed app, can I just change the passwords? Changing credentials to lock out a client who is currently operating a system they already had legitimate access to carries real risk under Section 43 of the IT Act, because you would be denying access to a person who was authorised to have it at the time. This is different from never having granted that access in the first place. If you are considering this step, get specific legal advice on your facts before acting, not after.