Website Development Agreement in India and Who Owns the Code

You paid a developer or an agency to build your Shopify store, so you assume the code is yours. Under Indian copyright law, that is not automatic. The person who writes the code is its first owner unless a signed written assignment says otherwise, and a vague clause can leave you with rights that run out after five years or stop at the Indian border. This guide covers what the Copyright Act actually says, what a Shopify build contains, and the clauses your website development agreement needs.

Statute text is quoted from the Copyright Office's published copy of the Copyright Act, 1957 and the Gazette copy of the Digital Personal Data Protection Act, 2023. Shopify rules are from Shopify's Help Centre and developer documentation. All were checked on 23 October 2026. This is a practical guide from a Shopify development team, not legal advice. Have a lawyer review your final agreement.

Who owns the code when you pay a developer in India?

The author owns it first. Section 17 of the Copyright Act, 1957 opens with: "the author of a work shall be the first owner of the copyright therein." Code is covered, because section 2(o) says a literary work "includes computer programmes."

There are exceptions, and founders usually assume one of them applies. Two matter here.

• Employees. Section 17(c) makes the employer the first owner of work made "in the course of the author's employment under a contract of service or apprenticeship," unless agreed otherwise. That covers developers on your payroll. A freelancer or an agency works under a contract for services, not a contract of service, so this exception does not hand their code to you.
• Commissioned work. Section 17(b) gives ownership to the person who pays for a photograph, painting, portrait, engraving or cinematograph film made "for valuable consideration at the instance of any person." Computer programmes are not on that list.

Read together, the plain text says this: paying an outside developer for code does not, by itself, make you the copyright owner. You become the owner through an assignment, and section 19 sets out what a valid assignment needs.

One detail founders miss: when you hire an agency, the developers who write your code are usually the agency's employees. Under section 17(c), the agency owns their work, not the individual developers. So the assignment has to come from the agency as a company, signed by someone authorised to sign for it.

What happens if the agreement is silent or vague?

Section 19 fills the gaps, and its defaults do not favour a growing brand. If there is no written assignment at all, there is no valid assignment. Section 19(1) says no assignment "shall be valid unless it is in writing signed by the assignor or by his duly authorised agent." An email saying "the code is yours" or an invoice marked paid is not that document.

If there is an assignment but it leaves things out, these defaults apply:

• Duration. Section 19(5): "If the period of assignment is not stated, it shall be deemed to be five years from the date of assignment."
• Territory. Section 19(6): if the territorial extent is not specified, "it shall be presumed to extend within India." That matters if you sell to the UAE, the US or the UK through Shopify Markets.
• Use it or lose it. Section 19(4): if the assignee does not exercise the assigned rights within one year of the assignment, the assignment for those rights "shall be deemed to have lapsed," unless the assignment says otherwise.

Section 19(2) adds that the assignment "shall identify such work, and shall specify the rights assigned and the duration and territorial extent." Section 19(3) asks for the royalty and any other consideration to be stated. A one-line clause that says "all IP belongs to the client" does none of this. It names no work, no duration and no territory.

The practical risk is rarely a developer turning up years later to sue. It is quieter than that. You change agencies, the old one disputes the final invoice, and suddenly the theme code, the custom app and the repository are things they control and you need. Or a buyer or investor asks you to show that you own your store's code, and you cannot produce a signed document that does.

What does a Shopify build actually contain, and who holds each part?

Ownership on Shopify is not one question. A typical build has six or seven separate pieces, and each one sits in a different place.

Three of these have Shopify rules that a contract cannot override, so they need to be designed into the project rather than fixed later.

Paid themes are licences, not property. Shopify says a theme bought from the Theme Store "is licensed exclusively to the store where the purchase was made," and that "a theme can only be used on one store at a time." On Shopify Plus, each storefront needs its own licence, including expansion stores and development or staging stores. See Shopify's page on theme licensing and transfers. So when the developer builds on a purchased theme, you own at most their changes, and the licence for the base theme belongs to the store it was bought for. Make sure it is bought on your store, not on the developer's development store.

Custom apps live in an organisation. Shopify now has you create custom apps in its Dev Dashboard, and custom apps created in the Shopify admin before 1 January 2026 are treated as legacy apps. Every app sits inside an organisation. If your developer creates your custom app in their own organisation, the app record, its client ID and secrets, and its settings are in their account, even if the code is assigned to you. Shopify's distribution documentation also says a custom distribution app can be installed on a single store, on several stores in the same Plus organisation, or on development stores, and that "you can't change the distribution method after you select it." If the app is likely to be needed on a second store that is not in the same Plus organisation, plan for that before it is created.

Store ownership moves only through Shopify's transfer flow. Some developers build in a client transfer store, which they own until you accept the transfer. Shopify's client transfer store guide says that after the transfer, "the merchant owns the store and it leaves your organization," and that a store with certain active Shopify financial products cannot be transferred. That route is fine if the contract fixes when the transfer happens. The simpler route is to open the store in your own name and give the developer collaborator access. Shopify lets you require a request code before a collaborator can ask for access, collaborators do not count towards your store's user limit, and you can remove their access from your admin. Our guide to collaborator accounts and developer access covers the setup.

Which clauses should a website development agreement include?

These are the ownership clauses we would expect to see in an agreement for a Shopify build in India. Take them to your lawyer as a checklist, not as drafted wording.

1. The right party assigns. The assignor is the legal entity that employs the developers, and the person signing has authority to bind it. If the agency uses freelancers, the agency confirms it has taken an assignment from each of them first.
2. The work is identified. List the deliverables: theme files and sections, custom app source code, theme app extensions, Shopify Functions, scripts for integrations, design files and documentation. Section 19(2) asks for the work to be identified, and a list is the easiest way to do that.
3. Future work is covered. Section 18 lets the prospective owner assign copyright in future work, and says that assignment "shall take effect only when the work comes into existence." Ask for an assignment of the work as it is created, rather than a promise to sign one at the end.
4. Duration is the full term. State that the assignment is for the full term of copyright. Without it, section 19(5) reads in five years.
5. Territory is worldwide. State it. Without it, section 19(6) reads in India only.
6. Lapse is switched off. Section 19(4) lets the assignment itself provide otherwise, so include a line that the assignment does not lapse if a right is not exercised within a year. Code written for a future feature or a second store often sits unused for longer than that.
7. Consideration is stated. Say that the project fees are the full consideration for the assignment, so section 19(3) is met and there is no argument about a separate royalty.
8. Pre-existing code is licensed. The developer keeps their own reusable libraries and starter code. In return, you get a perpetual, irrevocable licence to use and modify that code on your stores, including future stores.
9. Third-party components are listed. Paid themes, app subscriptions, fonts, icon sets and stock images are bought in your name, on your account, under their own licences.
10. Accounts are yours. You own the Shopify store, the code repository, the Dev Dashboard organisation for custom apps where that is practical, the hosting for any app server, the domain and DNS, and every payment gateway and API key. The developer gets collaborator or member access.
11. Handover is defined. State what is delivered at the end and when: repository access, deployment notes, environment variables, credentials rotated after the developer's access ends. Link the handover to the final payment, so neither side holds the other hostage.
12. Customer data is protected. Covered in the next section.

Two of these clauses are worth arguing over before you sign, because they are the ones disputes turn on: the account ownership clause and the handover trigger. If you are reading a proposal now, our guide on how to read a Shopify quote covers the rest of the document.

Why does the DPDP Act belong in a Shopify development contract?

Because your developer will see your customers' personal data. Building and testing a store means working with orders, addresses and phone numbers, and integrations with WhatsApp tools, couriers or an ERP move that data around.

Under the Digital Personal Data Protection Act, 2023, your business is the Data Fiduciary. Section 8(2) says a Data Fiduciary may involve a Data Processor to process personal data on its behalf "only under a valid contract." An agency with admin access to your orders is very likely acting as your processor for that work.

The Act's obligations are being brought into force in phases under the DPDP Rules, 2025, so confirm the current dates with your lawyer. There is no good reason to wait for them. A short clause covers the basics:

• The developer processes personal data only to deliver the agreed work.
• Access uses named collaborator or staff accounts, not shared logins.
• No customer data is copied to personal laptops, spreadsheets or test tools without your written approval.
• The developer tells you promptly about any breach they discover.
• Data and credentials are deleted or returned when the engagement ends.

What can a developer fairly keep?

An agreement that grabs everything gets pushback, and it should. A fair agreement leaves the developer three things.

Their tools. Every competent team has boilerplate, utility snippets and patterns it reuses across clients. Assigning those to you would stop them working for anyone else, so a licence is the right answer. You need permanent use on your stores, not exclusive ownership of their toolkit.

Their know-how. Copyright protects code, not ideas. A developer who learnt how to build a size-guide section on your project can build a different one for someone else.

A portfolio mention, with your permission. If you are under NDA or pre-launch, say so in the agreement.

What a developer should not keep: the only copy of your repository, the owner role on your store, the organisation that holds your custom app, or API keys issued in their personal name. Those are not intellectual property questions. They are access, and access is what turns a payment dispute into a business problem.

What should you do if your store is already live without these clauses?

Do not panic, and do not start with a legal notice. Most developers will sign a clean assignment when asked politely, especially while the relationship is good. In order:

1. Check where things are. Who is the store owner? Which organisation holds each custom app? Whose GitHub or Bitbucket account holds the code? Who pays for app hosting? Who owns the domain?
2. Move the accounts first. Store ownership, repository ownership and domain control are worth more in practice than a perfect clause, and they are easier to fix while the developer is still cooperative.
3. Ask for a confirmatory assignment. A short document that identifies the work already delivered, assigns it for the full term, worldwide, with the lapse rule switched off, and is signed by the right entity.
4. Fix the agreement for the next phase. If the work continues, update the contract before the next milestone, not after.

If you are changing developers anyway, our developer handover checklist covers the technical side, and the checks before final payment guide covers what to verify before the last invoice is paid.

Get a free ownership check on your Shopify build

Send us your development agreement or statement of work, or just tell us how your store was built. We will map every part of it (store, theme licence, custom code, custom apps, repositories, hosting, accounts and data access) to who holds it today, and list what is missing. We are a Shopify development team, not lawyers, so we will point out the gaps for your lawyer to close rather than draft the legal wording. If the agreement already covers everything, we will tell you that too.

Email hello@exactwhy.com with the subject line "Shopify ownership check" and attach the agreement or a short note on who built what. We reply within 4 hours.