Who owns your app? The ownership and handover traps when you get one built in India

Here is a conversation I have had more times than I would like. A business owner comes to me, often stressed, sometimes close to tears. They have an app. It is live. It has real customers on it. They paid a developer or an agency good money to build it, sometimes a few lakh rupees, and everything was fine for a year. Then the developer stopped replying. Or they wanted to switch to someone new. Or the developer quietly raised their monthly fee and said, in effect, pay this or your app goes dark.

And that is when they discover the thing nobody told them at the start: they do not actually own their own app.

Not the code. Not the account it lives in on the Play Store. Not the database where their customers' names and phone numbers are sitting. On paper, the app is theirs. In reality, every lever that controls it is in someone else's hands. Paying the bill, it turns out, was not the same as owning the thing.

This post is about making sure that never happens to you. I am going to explain, in plain English, what it actually means to own an app, why Indian law hands the default ownership to the developer and not to you, the seven separate things you need to control, the exact traps I see people fall into, and a simple one-page checklist you can put in front of any developer before you pay them a rupee. If your app is already built and you are now a little worried, there is a section near the end on what to do about that too.

None of this requires you to become technical or to distrust everyone. Most developers are honest and will happily hand you everything. The point is to make ownership a clear, boring, written thing at the start, so it never becomes an ugly, expensive surprise at the end.

The uncomfortable default: in India, your developer owns the code

Let me start with the fact that shocks people the most, because everything else makes more sense once you understand it.

You would assume that if you pay someone to build software for you, the software is yours. That is the common-sense view. It is also, under Indian law, wrong by default.

Copyright in software in India is governed by the Copyright Act, 1957. Its basic rule, in Section 17, is that the author of a work, the person who actually created it, is its first owner. There is a clear exception for employees: if someone writes code as part of a job, on your payroll, under your control, the work generally belongs to you, the employer. That is a "contract of service".

But an outside freelancer or an agency is not your employee. You have engaged them under what the law calls a "contract for service", a very different thing. And Indian courts do not decide which one it is by the label on the document; they look at the substance, who controls how the work is done, who bears the risk, whose tools are used, how integrated the person is into your business. An agency working from its own office, on its own machines, for many clients, is almost never your employee. So for that commissioned work, the developer remains the first owner of the copyright, and it stays with them until they hand it over.

How do they hand it over? Only one way: a written assignment. Section 19 of the same Act says no assignment of copyright is valid unless it is in writing and signed by the person giving it up. A verbal promise does not do it. An invoice stamped "paid in full" does not do it. A friendly WhatsApp message does not do it. The copyright moves only when there is a signed document that moves it.

And it gets sharper. Section 19 also says that if such an assignment does not specify how long it lasts, the law treats it as lasting only five years. If it does not specify a territory, it is presumed to cover India only. So even a sloppy, half-written assignment can quietly expire, or fail to cover you outside India, in ways you would never expect.

I am not telling you this to frighten you or to make you suspicious of good people. I am telling you because the fix is genuinely simple and completely fair. You put one plain clause in your agreement, before work begins, that says: on full and final payment, all source code, copyright and intellectual property in this app transfer to me, worldwide and forever. A developer who intends to hand you your app has zero reason to refuse that clause. Their willingness to sign it, or their squirming when you ask, tells you almost everything you need to know.

The single most useful sentence you can add to any app agreement: "On full payment, all source code, copyright and intellectual property pass to the client, worldwide and in perpetuity." If a developer resists this one line, pay very close attention.

"The app" is really seven things. You must own each one.

When an owner says "I want to make sure I own my app", they almost always mean the code. The code matters, but it is only one of about seven separate assets, and I have watched people get badly trapped by every single one of the others while the code sat safely on their laptop.

Here is the full list. Print it. Go through it for your own project, one line at a time, and write down whose name each one is in.

Notice that only the first two are about "the code" at all. The most painful lock-ins I see in real life are the other five. An app published in an agency's Play Store account. A database only the developer can log into. A payment gateway registered under the developer's PAN instead of the business's. A domain quietly renewed on the developer's personal card. Each one is a small thing that becomes a very large problem the day the relationship changes.

So the real question of ownership is not "do I have the code?" It is, for every one of these seven, "whose name is this in, and could I take it over tomorrow without needing this person's cooperation?" If the answer to the second half is no, you do not fully own that piece, however friendly things are today.

The account trap, and why you should own your own store accounts

Of all seven, the store accounts catch the most people, so they deserve their own section.

When your app goes on the Play Store or the App Store, it has to live inside a developer account. That account belongs to whoever registered it. If your developer or agency registered it in their name and simply published your app inside it, then the listing, the reviews, the download numbers, and crucially the button that pushes updates, are all under their control, not yours. Your app is a tenant in their house.

While everyone is getting along, this is invisible. It becomes a crisis at exactly the worst moment: when you want to leave, or they go quiet, or a payment dispute starts. Now the person you are unhappy with is the only one who can update your app, respond to a store policy warning, or ship an urgent fix. I have seen an owner unable to push a critical bug fix for weeks because it was stuck behind a developer who had stopped answering the phone.

Can you move an app out of someone else's account? Yes, but it is a formal transfer, and it needs their cooperation. On Android you request it through the Play Console; Google documents the process, and while it does carry over your users, reviews, ratings and stats, it needs both accounts fully set up and takes a few days. On Apple it is fussier still. Apple's transfer rules require the app to have at least one released version, both accounts to be active and enrolled, the app not to be in pre-order, and, in a trap that catches many, an app that uses "Sign in with Apple" cannot be transferred at all. Imagine finding that out only when you try to leave.

The clean answer removes all of this. Own your own developer accounts from day one. A Google Play account is a one-time 25 US dollar registration for the life of the account. An Apple Developer Program membership is 99 US dollars a year. Open both in your own name and business, then add your developer as a user with the access they need to work. Now your app lives in your house, your developer is a helper you invited in, and the day you part ways you simply remove their access and keep absolutely everything. The few thousand rupees this costs is the cheapest insurance you will ever buy.

What a real handover looks like (and what a fake one looks like)

Let us say ownership is sorted on paper. The project ends and it is time to actually hand everything over. This is where "give me the code" quietly fails, because a handover is a real event with real parts, and most people never test whether it actually worked.

A fake handover is a zip file. The developer emails you a folder of code, says "here you go, you have everything", and disappears. It feels like a handover. It is almost useless. You cannot build that code into a working app, you do not have the accounts it needs, you do not have the keys that make its features work, and you do not understand how any of it fits together. You have received the ingredients and none of the kitchen.

A real handover has six parts:

1. The code repository, in your name. Not a one-time zip, but access to the live repository (usually on GitHub or similar) added under your own account, with the full history. This matters because a repository you own cannot be quietly taken back, and the history lets a future developer understand how things were built.
2. The ability to rebuild and re-publish. The store accounts, the app "signing keys" (the digital identity that lets updates be accepted as genuinely yours), and clear, written build instructions. Without the signing key, in particular, no one can ever update your Android app under the same listing again. Losing it is a genuine disaster, so confirm you have it.
3. Every account and password. The backend server, the database, the domain, and every third-party service, payments, SMS, maps, notifications, analytics, with logins transferred to you or created in your name.
4. The keys, and where they live. The API keys that connect all those services, and a note of exactly where each one is stored in the code and the accounts.
5. A plain-English map. A short document, even two pages, that explains how the pieces connect: what the server does, where the data lives, which service handles what. This is the difference between a new developer taking two days to get oriented and taking two weeks.
6. A support window. An agreed period, say two to four weeks, where the original developer will answer a reasonable number of questions from you or a new team. Handovers always throw up small questions; this makes them cheap to resolve.

Here is the honest test of whether a handover was real, and I want you to actually use it: could a different developer, given only what you were handed and nothing else, successfully deploy a small update to your live app without ever contacting the original developer? If yes, you truly own your app. If no, you own a folder of files and a false sense of security. When the stakes are high, do not assume, test it, ideally while the first developer is still around to fill any gaps.

A worked example: Meera's boutique app, two ways

Let me make this concrete with a composite example, built from the kinds of cases I actually see. Meera runs a boutique. She gets an app built so customers can browse new arrivals, book fittings, and pay. She pays 2.5 lakh rupees over three months. The app is lovely. Fourteen months later, she wants to add a festival collection and a loyalty feature, and her original developer has become slow and expensive. She decides to bring in someone new.

The way it goes wrong. Meera never discussed ownership; she assumed paying meant owning. It turns out the app is published in the agency's Play Store account. The code is on the agency's private server. The database, with 4,000 customer names and phone numbers, is in a cloud account under the agency's email. The payment gateway is registered in the agency's name, so customer payments actually land in the agency's settlement account and are forwarded to her. When she says she is leaving, the relationship sours. The agency is under no written obligation to hand anything over. Getting her own customer list back becomes a negotiation. Moving the app needs a transfer they are slow to help with. The new developer cannot even start without access nobody will give. Meera has, in a real sense, been renting her own business. Untangling it costs her two months and a lot of money, and she is lucky it was possible at all.

The way it goes right. Before any work began, Meera's agreement had three plain clauses: on full payment, all code and IP become hers; all accounts and services are created in her name or transferred to her; and final handover of everything is the last milestone, tied to her final payment. During the build, the app was published in her Google Play account (25 US dollars, opened in an afternoon), the code lived in a repository under her login, and the payment gateway was registered to her business so money came straight to her. When she decided to switch developers, there was no drama at all. She removed the old developer's access, added the new one, handed over a two-page map document she had insisted on at the end of the build, and the new developer shipped the festival collection in a fortnight. Same app, same money spent on the build. The only difference was a page of ownership terms agreed before she paid.

The entire gap between these two stories is decisions made in the first week, when Meera had all the leverage, versus decisions avoided until the last week, when she had none. That is the whole lesson of this article in one example.

The one-page ownership checklist to settle before you pay

You do not need a 40-page legal contract to protect yourself, though for a serious business a lawyer reviewing your agreement is money well spent. You need clarity on a small number of points, agreed in writing, before the final payment leaves your hands. Here is the checklist. Walk through it with any developer or agency you are about to hire.

• Copyright and code: "On full payment, all source code, copyright and IP in the app transfer to me, worldwide and in perpetuity." One clause. Signed.
• Accounts in my name: The Google Play account, Apple account, domain, server, database and payment gateway are opened in my name and business, or transferred to me at handover. The developer gets access as an invited user, not as the owner.
• The signing keys: I receive the app's signing keys and confirm I can update the app under the same listing. (Ask this explicitly; it is the most commonly forgotten item and the most expensive to lose.)
• Everything I need to run it: All logins, passwords, API keys, and a plain-English document explaining how the app is put together.
• A tested handover: Handover is the final milestone, and my final payment is tied to it. Ideally, a second person confirms they can deploy an update using only what was handed over.
• A support window: The developer will answer reasonable questions for an agreed period (say two to four weeks) after handover.
• My data is mine: All customer data belongs to me, is handed over in a usable format, and the developer will not keep or reuse it after we part.

If you want to go deeper on how to scope the build itself so you get the app you actually pictured, I wrote a full guide on how to brief a developer or an AI; the ownership checklist above sits naturally at the end of that same brief. And once the app is yours and live, the running costs and upkeep are their own topic, which I covered in what app maintenance actually costs after launch.

The honest trade-offs: you don't always need to own everything on day one

I would be breaking my own rule about honesty if I told you to demand total ownership of everything on every project from the first minute. Sometimes that is the wrong call, and pretending otherwise would cost you speed and money you may not have.

If you are building a quick, cheap MVP, a first version whose entire job is to test whether an idea has any life in it, then a lighter arrangement can be sensible. It might be fine to launch temporarily inside a developer's account to move faster, or to share some tooling early, on the clear understanding, in writing, that ownership and the app transfer to you if the idea proves out. When you might throw the whole thing away in a month, spending days setting up your own accounts and a full legal handover can be effort in the wrong place.

There is also a middle path worth knowing about for higher-stakes work where you are not ready to take the code in-house but you are worried about the developer disappearing: source code escrow. This is a well-established arrangement where a neutral third party holds a copy of your source code, and releases it to you only if a specific event happens, typically the developer going out of business or failing to maintain the software as promised. It is more common with larger software deals than small apps, and it costs money, but for a business betting a lot on a single external developer, it is a real option that sits between "trust completely" and "own everything now".

The point of this whole article was never paranoia. It is a clear, written decision about who owns what and when. Match the formality to the stakes. A five-figure experiment needs a simple, honest one-page agreement. A business you are staking your livelihood on needs you to own your accounts, your data and your code from the start, and probably needs a lawyer to read the contract. The genuine mistake is not sharing something early to move fast. The genuine mistake is never deciding, drifting along on good vibes, and discovering the answer to "who owns this?" only on the day the good vibes end.

A good studio, by the way, wants you to own your app. It is a sign of confidence, not weakness. We build things we are proud to hand over completely, because a client who owns their app fully and comes back for the next one is worth far more than a client trapped by a login. If a developer's business model quietly depends on you not being able to leave, you have learned something important about them before it cost you anything.

Where to go from here

If you are about to get an app built, do one thing before you sign anything: take the one-page checklist above and put it in front of the person you are hiring. Watch how they react. Clarity here is free, and it will save you from the single most avoidable and most painful dispute in this whole business.

If your app already exists and reading this has made you uneasy, do not panic and do not pick a fight. Make the list of seven assets, mark honestly whose name each is in, and then approach your developer calmly to formalise what may simply never have been written down. Most of the time, it gets sorted with a signature and a few account invites.

And if you would rather have someone build your app the right way from the start, with you owning the code, the accounts and the data, in writing, from day one, that is exactly how we work at the Roy Digital App Studio. You should own your business. Your app is your business. It should be no different.