Who Owns the Code When You Hire a Development Studio?

You paid for the software. You assume you own it. That assumption is wrong more often than founders expect. Who owns the code is not decided by who wrote the check. It is decided by the contract, the account setup, and how the work gets handed over. Software development IP ownership is one of the few decisions that can quietly cost you your whole company, and most founders never read the paragraph that controls it.

This is a practical walk through what ownership actually means, how different builders handle it, and what to confirm before you sign anything. It is general information, not legal advice.

Why who owns the code matters more than founders realize

Your code is not just a feature list. It is the asset an acquirer buys, the thing an investor does diligence on, and the leverage a partner uses if the relationship goes bad.

Here is where founders get hurt:

Fundraising stalls. An investor's lawyer asks for a clean chain of IP ownership. If a past contractor never signed an assignment, that gap can freeze a round.
Acquisitions fall apart. During due diligence, a buyer finds the studio still holds the copyright or the hosting account. The deal gets repriced or dropped.
You get held hostage. You want to switch teams, but the current one controls the repository, the domain, and the server logins. Leaving means rebuilding.

None of this shows up while things are going well. It shows up at the exact moment you have leverage to lose.

Work-for-hire vs licensing: the difference that decides everything

Two contract structures sound similar and mean opposite things.

Work-for-hire (with assignment). You commission the work and the builder assigns all rights to you. You own the copyright. You can sell it, change it, or hand it to another team. This is what you want.

Licensing. The builder keeps ownership and grants you permission to use the software. You are renting. The terms can restrict what you do, expire, or come with ongoing fees. Some agencies build on a proprietary framework and license that layer to you, which means part of your product is never yours.

The label "work-for-hire" alone is not enough. Under US copyright law, work-for-hire only applies automatically to employees, or to specific commissioned categories. For most custom software from a contractor, you need an explicit, written assignment of IP to be safe. A contract that says "work-for-hire" without an assignment clause can leave rights with the person who wrote the code.

What "ownership" should actually include

Owning the code is not the same as owning the product. Real ownership is the full set of things needed to run, change, and move your software without asking anyone's permission.

Confirm you get all of this in your name:

Source code and the Git repository, including full commit history, not a zipped snapshot.
Cloud and hosting accounts (AWS, Google Cloud, Vercel, and similar), owned by you, billed to you.
Domains and DNS, registered in your name at a registrar you control.
Third-party service accounts: database, email, payments (Stripe), analytics, error tracking.
Design files: Figma, brand assets, and source design files, not just exported images.
Credentials and secrets: API keys, environment variables, admin logins, all documented and handed to you.
CI/CD and deployment config so you can ship updates without the original team.

If any one of these sits in someone else's account, you do not have full control. You have a dependency.

How agencies, freelancers, and AI tools each handle it

Each path has a different failure mode. For a fuller side-by-side, see our breakdown of agency vs freelancer vs studio.

Agencies

Some agencies are clean. Others build IP retention into the business model. Watch for contracts where the agency keeps ownership of shared components or "the platform," hosts everything on their master accounts, and charges you to migrate off. It can feel convenient until you want to leave. Then you learn the domain and the server were never yours.

Freelancers

A good freelancer will transfer everything. The problem is usually messiness, not malice. Accounts get created under the freelancer's personal email, the repo lives on their GitHub, and the assignment clause is missing from a lightweight contract. When they move on, transfers get half-done or forgotten, and you are left chasing logins from someone who has stopped replying.

AI coding tools and vibe coding

You typically own output you generate with an AI tool, so ownership on paper is not the issue. Maintainability is. Vibe coding tends to produce a codebase no one fully understands, with no tests, no structure, and no one to call when it breaks. You own it, and you still cannot ship a change safely. We cover this in detail in vibe coding limits.

IP assignment clauses to look for in a contract

You do not need to be a lawyer to spot the right language. Look for these:

Present-tense assignment. "Contractor hereby assigns" transfers rights now. "Contractor agrees to assign" only promises a future step that may never happen. The wording matters.
All deliverables and work product, including code, designs, documentation, and configuration, named explicitly.
Assignment triggers clearly, ideally on creation, not gated behind final payment. If payment is a condition, understand exactly when ownership passes.
Moral rights waiver where applicable, so the author cannot object to changes you make later.
Third-party and open-source disclosure. The contract should list any open-source licenses used and confirm nothing restricts your commercial use.
Cooperation clause. The builder agrees to sign any further documents needed to perfect your ownership, which matters during a future fundraise or sale.

Read the payment and termination sections too. Ownership that only transfers after a final invoice can trap you if a dispute freezes that payment.

A pre-hire ownership checklist

Confirm every item below before you sign. If a builder hesitates on any of these, treat it as a signal.

The contract includes a present-tense IP assignment of all work product to you or your company.
Ownership transfers on creation or delivery, not only after final payment (or the timing is spelled out and acceptable).
All accounts (hosting, domain, third-party services) will be created in your name, or transferred to you.
You receive the full Git repository with history, not a code dump.
Design source files are included, not just exports.
All credentials and secrets will be documented and handed over.
Any open-source or third-party components are disclosed with licenses that allow commercial use.
There is a cooperation clause for future paperwork (fundraising, acquisition).
There is no clause letting the builder retain, license back, or hold hostage any part of the product.
You can walk away with everything at any time, with no exit fee.

Budget affects some of these choices too. If you are still weighing options, see what it costs.

What full ownership on day one looks like in practice

The cleanest setup is one where there is nothing to transfer later because everything was yours from the start.

In practice that means:

The repository is created under your GitHub or GitLab organization on day one. The team gets access as collaborators, not owners.
Hosting, domain, and every third-party account are opened in your name, billed to your card.
Credentials live in a vault you control. The team uses them; they do not hold them.
The contract assigns IP to you at creation, so ownership is never in question.
Support is optional. The team stays on because you want them to, not because you cannot leave.

That is the standard we build to at Unilo Studio. You own 100% of the code, repositories, accounts, infrastructure, domains, and credentials from the first commit. If you ever want to take it all somewhere else, you can, without a conversation about who owns what.

Key takeaways

Paying for code does not mean owning it. The contract and the account setup decide ownership, not the invoice.
Get a present-tense IP assignment. "Hereby assigns" is what you want, not "agrees to assign."
Ownership is more than code. It includes repos, accounts, infrastructure, domains, design files, and credentials.
Each builder type has a trap: agency lock-in, freelancer mess, and unmaintainable AI-generated code.
The safest setup needs no handover because everything was in your name from day one.

Talk it through

If you want a second read on your setup, or you are choosing a team and want to get ownership right from the start, book a free 30 minute scoping call. We will walk through what you should own and how to keep it clean. Grab a time here, or email contact@unilostudio.com.