A founder pays to build an app, gets the launch, and assumes the code is theirs. Then the relationship sours, a new developer comes in, and suddenly access is limited, files are missing, or the contract says the agency keeps the intellectual property. That is usually the moment people start asking who owns custom app code — and by then, the leverage is gone.
TL;DR: Payment alone does not equal ownership. Without a clear written assignment clause, the developer often retains the IP by default. Before signing any development agreement, confirm you will receive the source code, design files, repos, credentials, and documentation — and that a new team could take over without asking permission. Vague language is a red flag, not a technicality.
The short answer: it depends on the contract
If you are paying for custom software, you might think ownership is automatic. It often is not. In many cases, the person or company that creates the code owns it by default unless a written agreement transfers those rights to the client.
That means payment alone does not always equal ownership. You can fully pay an invoice and still end up with a limited licence to use the software instead of owning the underlying codebase. That distinction matters when you want to switch vendors, raise funding, sell the business, or keep building the product without asking permission. If you are still deciding whether to build or buy, understanding what custom software ownership actually means should come before the contract conversation.
Why founders get this wrong
Most business owners do not spend their day reading IP clauses. They are focused on scope, features, timelines, and launch dates. Ownership language gets buried near the end of a proposal, mixed in with legal boilerplate, and everyone moves on.
The problem is that software is not like hiring a contractor to paint an office. Code is intellectual property. Ownership, licensing, reuse rights, and third-party dependencies all have to be spelled out clearly. If they are not, assumptions fill the gap — and assumptions are expensive.
Who owns custom app code under the law?
In general, the creator owns the work unless there is a valid written agreement transferring ownership. There are exceptions, particularly around employees and work-made-for-hire arrangements, but many agency-client relationships do not fit neatly into those categories.
If a developer is your employee, work created within the scope of employment is usually owned by your company. If a development agency or independent contractor builds the app, ownership usually depends on the contract language. Without a strong assignment clause, you may only have the right to use the finished product in a limited way.
This is why smart buyers do not ask vague questions like "Do I own the app?" They ask specific ones. Do I own the source code? Do I get the design files? Do I receive deployment credentials, repositories, documentation, and infrastructure access? Can the agency reuse parts of the system elsewhere? Those answers tell you what you are really buying.
The difference between owning code and licensing it
This is where deals get slippery.
Ownership means the intellectual property rights in the custom code are assigned to you. You control it. You can modify it, hire another team to maintain it, sell the product, or package it into a larger business asset.
A licence means you are allowed to use the software, but the creator still owns the underlying code. Some licences are broad and practical. Others are restrictive enough to trap you with one vendor.
Neither model is automatically wrong. A licence can make sense for a platform product or a shared framework. But if you are paying for a truly custom app intended to be a core business asset, full ownership is usually the cleaner and safer arrangement. The same logic applies when scoping a custom software project — ownership structure should be part of the brief, not an afterthought.
What the contract should say
If you want certainty, the contract should be direct, not clever. You want plain language stating that all custom code, designs, and deliverables created specifically for your project are assigned to your business upon final payment, or according to whatever milestone structure you agree to.
It should also explain what is not included in that transfer. Many agencies use pre-existing internal libraries, development tools, open-source components, and reusable methods across multiple projects. That is normal. The key is separating custom deliverables from pre-existing materials so there is no confusion later.
A strong agreement covers ownership of the custom source code, design assets, documentation, API integrations created for the project, and access credentials for environments tied to your app. It should also define any continuing licence the development partner retains to use its own background tools and generic know-how.
The grey area: reused components and frameworks
Most experienced development teams do not write every line from scratch for every project. They rely on proven components, starter architecture, internal utilities, and established libraries to move faster and reduce risk. That is good for quality and speed, but it creates a question: what exactly are you buying?
The fair answer is usually this: you should own the custom app code built specifically for your business logic, product workflows, user experience, and integrations. The agency may retain rights to pre-existing modules or generalised internal tools that are not unique to your business.
That is not a red flag by itself. It becomes a problem only when the reusable layer is so central that you cannot maintain or migrate the app without the original vendor. If your business depends on code you cannot legally control or practically access, you do not really own the product in any meaningful way.
Open-source software does not cancel your ownership
Many apps include open-source packages — that is standard practice. Using open-source software does not mean you cannot own your custom app code.
What it does mean is that parts of your stack may be governed by third-party licence terms. Some are very permissive. Others come with obligations around attribution or distribution. A responsible development partner should know what is being used and avoid introducing licensing problems that could create legal or commercial headaches later.
For most businesses, this is not a reason to panic. It is a reason to ask for transparency. You should know what third-party components are in the build and whether any of them create unusual restrictions.
Red flags that should stop the deal
Some ownership terms are clear enough to walk away from.
Be careful if the contract says the developer retains all intellectual property and grants you only a limited right to use the software. Be careful if source code delivery is optional, delayed indefinitely, or tied to extra fees not disclosed upfront. Be careful if repositories, hosting accounts, and deployment credentials stay under the vendor's sole control.
Also watch for vague language like "proprietary framework" or "platform dependency" when no one can explain what that means in practical terms. If moving the product to another team would be difficult, costly, or legally restricted, you need to know that before signing.
Questions to ask before the project starts
You do not need to become a lawyer. You do need to ask better questions.
Ask who will own the custom source code at the end of the engagement. Ask when ownership transfers. Ask whether all repos, credentials, documentation, and design files will be handed over. Ask what pre-existing code or internal tooling is excluded. Ask whether any third-party licences create restrictions. Ask whether a new team could take over the product without needing special permission.
If the answers are fuzzy, the risk is real. Understanding what custom software actually costs includes more than the development invoice — it includes the cost of dependency you did not plan for.
Why ownership matters more than most people think
Founders usually care about ownership once something goes wrong. The smarter move is to care before anything goes wrong.
Ownership affects valuation. If your company is building a SaaS product, investors and acquirers will want to know that the core technology is actually owned by the business. Ownership affects continuity too — if your current team becomes unavailable, you need the right and the ability to keep operating.
It also affects leverage. A business that owns its code can change direction, bring in specialists, improve performance, or reduce support costs without starting from zero. A business that does not own its code often pays for the same dependency twice — once during development and again every time it wants control. The case for launching a SaaS product with ownership built in from day one is exactly this.
The cleanest setup is simple: custom work built for your business should belong to your business. Any excluded materials should be clearly named. Access should never be held hostage. Documentation, repositories, and environments should be structured so another competent team can take over if needed.
Before you sign any development agreement, slow down long enough to read the ownership section like it is the most important part of the deal — because for your future flexibility, valuation, and control, it probably is.
Working with MyMind Studio? Ownership is straightforward: custom code built for your project is yours. Visit mymindstudio.ai/free-business-growth-audit for a free Business Growth Audit — or talk to the team before your next build.
Which accounts to open in your own name before the build starts
An assignment clause settles who owns the code. It does not settle who can log in. Control of a shipped app actually lives in six accounts, and they are wildly unequal: one has no self-serve transfer at all, two are conditional on paperwork that may be years old by the time you need it, two move but lose things on the way, and one is free and near-instant. Read the third column first and negotiate in that order. Platform fees below are the published figures as of August 2026, they vary by region, and you should re-check them on the vendor's own page before budgeting.
| Account or asset | Cost to open it in your own name at kickoff | If the agency opened it instead — how hard to get back? | The published rule that actually decides it | What to do before the build starts |
|---|---|---|---|---|
| Payments / payout account (your payment gateway) | No platform setup fee either way — Stripe, for one, publishes that it charges "no setup fees, monthly fees, or any other hidden fees"; the real cost is producing your own entity's KYC documents. | Hardest of the six. This is the row to fight for, and almost nobody negotiates it. | An account is tied to one legal entity and tax ID, so it is not a self-serve toggle: Stripe's own guidance for a business sale starts with contacting Support to confirm which details must change — legal business name, tax ID, bank account, company representative, business URL — and states that if the acquiring entity is in a different country, the process is different again. | Open the gateway under your own entity on day one and add the agency as a restricted team member; never let live payouts settle into the agency's entity, because the payout bank account on file belongs to whichever entity the account is registered to, and changing that is the support process described in the previous column. |
| Apple App Store (Apple Developer Program) | US$99 per membership year, plus a D-U-N-S number (free in most jurisdictions, but it takes time), a publicly available website on a domain associated with your organization, and an enrollee with legal authority to bind the company. | Conditional. Apple does support app transfer, but only if the app is in exactly the right state on the day you ask. | Apple requires at least one version already released, no pre-order, and no build sitting in Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release or Pending Apple Release; in-app purchase IDs must not collide with the receiving account's, TestFlight builds and testers must be cleared, Xcode Cloud data removed, Sign in with Apple groupings undone, both accounts on the latest agreements and not mid-change — and Apple Arcade apps cannot be transferred at all. | Enroll your own organization account early, since the D-U-N-S step is exactly what makes agencies offer to publish under theirs; keep yourself as Account Holder and give the agency App Manager or Developer roles. |
| Google Play Console | US$25, one time, for developer account registration. | Conditional, and it depends on the agency's paperwork years later. | Both accounts must be registered, active and policy-compliant, and the transfer request needs the registration transaction ID of both — found only in the owner's "developer registration fee" receipt email or their Google Payments activity — while Firebase projects must be unlinked and relinked, Analytics and Play Games Services access granted separately, ad SDK integrations shipped in a new APK, test groups recreated, and paid or in-app-purchase apps need a payments profile on the receiving account. | Register the Play account under your business and invite the agency as users; recovering an app later can hinge on a years-old receipt sitting in someone else's inbox. |
| Domain name (registrar account and registrant record) | Your registrar's normal annual renewal — the same either way. | Usually recoverable, but the timing bites if handover sits near a launch or a funding deadline. | Under ICANN's Transfer Policy the registrar "must impose a 60-day inter-registrar transfer lock following a Change of Registrant", and it may — but is not obliged to — let you opt out of that lock, and only before the change is requested, never during it. Two further 60-day windows let a registrar refuse a move: within 60 days of initial registration, and within 60 days of a previous transfer. ICANN's own advice is to do the inter-registrar transfer first and the registrant change after. The policy is under review at ICANN, so confirm the current rule with your registrar in writing. | Register the domain in your own registrar account from the start; if it already sits with the agency, move the name to your own registrar account first and change the registrant details after, ask whether an opt-out from the 60-day lock is offered before anything is touched, and keep 60 clear days between the handover and any launch or funding date. |
| Cloud project and backend (Google Cloud / Firebase; other providers are a similar shape, confirm separately) | The infrastructure bill is identical either way — the only thing that changes is whose name is on the billing account. | Movable but lossy. The project survives the move; a lot of its configuration does not. | Google Cloud documents that migrating a project between organizations drops every role granted at the source organization or folder level, replaces the source organization's policies with the destination's, does not bring inherited organization-level quotas, requires organization-level custom IAM roles to be recreated, and may cost you discounts or your support tier — on top of the Firebase relinking the Play row already demands. | Put the cloud organization and billing account in your company's name, give the agency project-level IAM rather than organization ownership, and get a written inventory of every third-party service in the build and whose account it sits in. |
| Source code repository (GitHub; GitLab similar) | US$0 — GitHub Free covers unlimited private repositories with unlimited collaborators, on a limited feature set. | Easiest of the six, which is the whole point of this table: it is the asset founders fixate on and the cheapest one to fix later. | Any repository admin can transfer it, and issues, pull requests, wiki, stars and watchers move with it while webhooks, secrets and deploy keys stay attached, Git LFS objects move automatically, and links to the old location redirect — the caveats are small (GitHub Pages sites are not redirected, issue assignments to anyone outside the receiving organization are cleared, read-only collaborators are dropped organization-to-personal, and a private repository landing on a Free account loses features such as protected branches and Pages). | Have the repository live in your organization from the first commit and add the agency as collaborators — then spend the negotiating capital you were about to burn here on the payments and store accounts instead. |
Where the "own it yourself" answer is wrong: a founder with no registered company yet cannot open a gateway or an Apple organization account at all, and holding the build hostage to a D-U-N-S application can cost more in lost weeks than the risk is worth — the fix there is a dated clause naming the transfer date and the party who pays for it, not a stalled kickoff. Insisting on organization-level cloud ownership is also a bad idea for a non-technical founder with nobody to administer it, since a misconfigured billing account you control is worse than a working one you can claim later. And paying an agency to move a repository is close to pure waste; that transfer is a free action anyone with administrator access to the repository can perform themselves.
Frequently Asked Questions
Does paying for custom software automatically mean I own the code?
Not necessarily. In most jurisdictions, the creator of the code owns it by default unless a written agreement explicitly transfers those rights to the client. Full payment of an invoice establishes that you have paid for the work, not that you own the underlying intellectual property. Ownership requires a clear assignment clause in the contract. Without it, you may only have a licence to use the software — not the right to modify it, resell it, or take it to another team without restrictions.
What is the difference between owning code and having a licence to use it?
Ownership means the intellectual property rights are assigned to you. You can modify the code, hire a different team to maintain it, sell it as part of the business, or build on it however you choose. A licence means the original creator still owns the code but has given you permission to use it under specific terms. Some licences are broad and practical. Others restrict what you can do with the software, who can work on it, and what happens if you stop paying. For any software that is central to your business, full ownership is almost always the better arrangement.
What should a software ownership contract include?
A clear ownership clause should specify that all custom code, design assets, documentation, and API integrations created specifically for your project are assigned to your business, either at project completion or at defined milestones. It should also name what is excluded — pre-existing agency libraries, third-party tools, or open-source components — so there is no ambiguity later. The agreement should also cover the handover of source code repositories, hosting and deployment credentials, and any infrastructure tied to the product.
Can a development agency reuse code they built for my project?
That depends entirely on the contract. If the agreement assigns full ownership to you, the agency cannot legally reuse the custom code created specifically for your project without your permission. However, most development engagements involve some pre-existing internal tools, frameworks, or utility libraries that the agency uses across multiple clients. Those are typically excluded from the ownership transfer. The key is to ensure the contract clearly defines what is custom to your project versus what the agency brought into the build. If that line is not drawn, disputes become likely.
What happens to my app if the development agency closes down?
If you own the code — meaning the IP has been assigned to you and you have access to all repositories, credentials, and documentation — the agency closing down has no practical impact on your product. You can take the codebase to another team and continue without interruption. If you only have a licence and the agency holds the repositories or infrastructure, their closure could leave you locked out or in a legally complicated position. This is exactly why asking about ownership, access, and what happens at the end of the engagement is not a paranoid question — it is basic due diligence.
