Note: This is general product and commercial guidance, not legal advice.
Copyright and contract law vary by country, and the US rules described here do
not apply everywhere. Nothing below replaces a lawyer reviewing your actual
agreement. Use it to know what to look for and what to ask.
TL;DR
Paying someone to write code does not make the code yours. Under US copyright
law, copyright vests initially in the author, so a contractor who writes your MVP
owns it until a signed agreement moves it. The clause that moves it has to say
the contractor "hereby assigns", present tense. A promise to assign later is
only a promise. And the "work made for hire" clause most contracts lean on
generally does not work for software, because commissioned software is not one
of the nine categories the statute allows. You want a present assignment, with
work-for-hire as a backstop, plus background IP, subcontractors, accounts and
open source all handled explicitly.
Key Takeaways
- The default is that the developer owns the code, not you. Copyright vests
initially in the author under 17 U.S.C. 201. - "Hereby assigns" transfers ownership now. "Shall assign" is a promise you
may have to enforce later, possibly against someone who no longer wants to help. - A work-for-hire clause alone is usually not enough for software. The statute
lists nine categories of commissioned work that can qualify, and software is not
among them. - Background IP is the quiet one. Agencies reuse internal libraries. If that
is not licensed to you properly, part of your product is not yours to sell. - Subcontractors break the chain. The freelancer who actually wrote the code
may have signed nothing with you at all. - Owning the code is not the same as controlling the product. Repository,
domain, app store and hosting accounts must be in your name from day one. - Open-source components need disclosure. Some licences carry obligations
that can affect how you ship or sell. - The time to fix all of this is before signing, when you still have leverage.
At a Glance
| Clause | What happens without it |
|---|---|
| Present-tense IP assignment | The developer keeps ownership of your product |
| Work-for-hire backstop | Your only assignment route can fail on a technicality |
| Background IP licence | Part of your codebase is licensed, not owned |
| Subcontractor flow-down | The person who wrote the code never assigned it |
| Accounts in your name | You own code you cannot deploy or update |
| Open-source bill of materials | Unknown licence obligations inside your product |
| Acceptance criteria | No agreed definition of what "finished" means |
| Exit assistance | A handover that stalls exactly when you need it |
Why paying for code does not mean owning it
This is the part that surprises almost every non-technical founder, and it is not
a loophole. It is the default rule.
Under 17 U.S.C. 201, copyright
in a work vests initially in its author. When an independent contractor or agency
writes software for you, the author is them. Your payment buys the service. It
does not, by itself, transfer the copyright in what that service produced.
What you get without an assignment is, at best, an implied licence to use the
software for its intended purpose. That may feel like ownership right up to the
moment it matters, which is usually one of three moments: an investor's legal
team runs diligence before a round, an acquirer asks you to warrant that you own
your product, or you decide to leave the agency and take the codebase with you.
Employees are different. Work created by an employee within the scope of their
employment is a work made for hire, and the employer is treated as the author.
That is why this problem shows up with agencies, contractors and freelancers
rather than with staff.
The two words that decide everything: "hereby assigns"
If you read only one clause in the whole agreement, read this one, and check its
tense.
"Contractor hereby assigns" is a present assignment. Ownership moves on
signature, automatically, as the work is created. Nothing further is required
from anyone.
"Contractor shall assign" or "agrees to assign" is a promise to do
something in the future. It creates an obligation, not a transfer. You own
nothing yet. To get ownership you need them to actually execute the assignment
later, and if the relationship has broken down by then, you are chasing a
counterparty who has no incentive to help, possibly in another jurisdiction.
The practical consequence is disproportionate to the wording. Diligence teams
look for this specific tense. A future-promise clause is a finding that has to be
cured, which usually means going back to a former contractor and asking them to
sign something, at exactly the moment you have the least leverage and the least
time.
Good agreements often use belt and braces: a present assignment, plus a covenant
to execute any further documents needed to perfect it, plus a limited power of
attorney so you can record the transfer if they become unreachable.
Why the work-for-hire clause usually is not enough
Most software development agreements contain a "work made for hire" clause.
Founders read it and relax. For contractor-written software, it frequently does
not do what people think.
17 U.S.C. 101 defines a work
made for hire in two ways. The first is work by an employee within the scope
of employment, which does not describe an agency or freelancer. The second covers
work specially ordered or commissioned, but only if it falls into one of nine
enumerated categories and the parties agree in writing:
| The nine commissioned categories |
|---|
| A contribution to a collective work |
| A part of a motion picture or other audiovisual work |
| A translation |
| A supplementary work |
| A compilation |
| An instructional text |
| A test |
| Answer material for a test |
| An atlas |
Computer software is not on that list. So when an independent contractor
writes your MVP, a work-for-hire clause standing alone can fail, and if it fails
and there is no assignment behind it, ownership stays where it started.
This is exactly why well-drafted agreements pair the two: work for hire where
applicable, and a present assignment that operates if for any reason the work
for hire provision does not apply. The second half is the one doing the real
work. See the US Copyright Office's Circular 30
for the official treatment.
Background IP: the part of your product that stays theirs
Every competent agency reuses internal code. Boilerplate, auth scaffolding,
deployment tooling, component libraries. This is a good thing, and it is a large
part of why they can move fast.
It also means some of what ships in your product was not written for you and will
not be assigned to you. That is normal and acceptable. What is not acceptable is
leaving it undefined.
What you want is:
- A named schedule of background IP. Actually listed, not described as
"materials the Contractor may incorporate". If it is not written down, you
cannot know what you own. - A broad, perpetual, irrevocable, royalty-free, worldwide licence to use,
modify, sublicense and distribute that background IP as part of your product,
including after the relationship ends. - The right to keep using it if you switch developers, which is the scenario
the clause exists for.
The failure mode here is quiet. Nothing goes wrong during the build. It surfaces
when an acquirer asks you to warrant that you own the product and you discover
that the authentication layer is licensed from your former agency on terms nobody
read.
Subcontractors: the person who wrote it may have signed nothing
You sign with an agency. The agency subcontracts to a freelancer. The freelancer
writes the code. You have a contract with the agency, and the agency has a
contract with the freelancer, but if that second contract does not itself assign
ownership onward, the chain of title has a hole in it.
The clause you want is a flow-down: the agency warrants that every employee,
contractor and subcontractor who touches your project has signed a written
agreement assigning their work, and that the agency has the right to pass that
ownership to you.
Ask directly whether any part of the work will be subcontracted, including
offshore. The answer is often yes and that is fine. What matters is that the
paperwork follows the people.
Moral rights
In many jurisdictions authors hold moral rights, such as the right to be
attributed or to object to derogatory treatment of their work. These are separate
from copyright and in some countries cannot be assigned at all, only waived.
For most MVPs this is a minor item, but a clause waiving moral rights to the
extent permitted by law costs nothing to include and removes an edge case.
Own the accounts, not just the code
Owning the copyright and being able to run your product are different things, and
founders routinely secure the first while losing the second.
If your repository lives in the agency's organisation, your domain is registered
to their account, your app store listing is under their developer account, or
your cloud hosting is on their billing, then a dispute or simply a slow handover
can take your product offline while you hold perfect title to code you cannot
deploy.
The rule is simple and worth insisting on from day one: every account is created
in your name, and the agency is granted access to it. Not the other way round.
That covers the code repository, the domain registrar, hosting and cloud, app
store and developer accounts, analytics, error tracking, email and payment
processing.
This is the same principle covered in how to protect your app idea,
and it is the one operational detail that most often turns a legal problem into
an outage.
Open source and the bill of materials
Your MVP will include open-source dependencies. That is normal and good. The
contract should require the developer to tell you what they are.
Ask for a bill of materials: a list of third-party and open-source components
with their licences. Most common licences are permissive and impose little beyond
attribution. Some are copyleft and carry conditions that can affect how you
distribute or sell the resulting product, particularly if you ever ship software
to customers rather than running it as a service.
You do not need to become an expert. You need the list, a clause requiring the
developer to comply with those licences, and a rule that anything unusual gets
flagged to you before it goes in. The Open Source Initiative
maintains the canonical list of approved licences.
Acceptance criteria, milestones and what "done" means
Ownership is the part that can sink you. Scope is the part that will annoy you
weekly. The contract should define:
- What is being delivered, referencing a scope document rather than a
paragraph of prose. Your requirements document
belongs here as an attachment. - Acceptance criteria per milestone, so "finished" is testable rather than a
matter of opinion. - Payment tied to accepted milestones, not to elapsed time or to signature.
- A change process that says what happens when scope moves, because it will.
- A defect period after each milestone, distinguishing a bug from a new
feature request.
How this interacts with pricing is covered in
fixed price versus hourly.
Exit assistance
The clause everyone skips, and the one you notice when you need it.
An exit assistance obligation commits the developer to hand over cleanly: source
code and full history, credentials and access, environment configuration and
deployment instructions, documentation, and a defined number of hours of
transition support at an agreed rate.
Without it, a handover depends on goodwill at precisely the moment goodwill has
run out. With it, leaving is a process rather than a negotiation.
Red flags in a development contract
| Red flag | Why it matters |
|---|---|
| "Shall assign" or "agrees to assign" | No transfer has happened yet |
| Work-for-hire clause with no assignment behind it | Can fail outright for software |
| Ownership conditioned on "full payment" with no definition | Leverage against you in any dispute |
| No mention of background IP at all | You cannot tell what you own |
| Silence on subcontractors | The chain of title may be broken |
| Repository or accounts in the agency's name | You own code you cannot ship |
| No list of open-source components | Unknown obligations inside your product |
| No acceptance criteria | "Done" becomes an argument |
| No exit assistance | Handover depends on goodwill |
| Reluctance to discuss any of the above | The most informative signal of all |
That last row deserves emphasis. Every item here is standard and reasonable. A
developer who reacts badly to being asked about ownership is telling you
something more useful than any clause. This pairs with the warning signs in
MVP agency red flags.
Questions to ask before you sign
- Does the assignment say "hereby assigns", present tense?
- If the work-for-hire provision fails, does an assignment still operate?
- What background IP will be used, and can I see it listed?
- What licence do I get to that background IP, and does it survive the contract?
- Will any work be subcontracted, and have those people assigned their work?
- Will every account be created in my name?
- Can I have a list of open-source components and their licences?
- What are the acceptance criteria for each milestone?
- What does handover look like if I take the project elsewhere?
- Is ownership conditional on anything, and if so, on what exactly?
You do not need a lawyer to ask these. You may well want one to read the answers.
How we handle it
We build MVPs on the basis that the product is yours from the first commit.
Present-tense assignment, accounts created in your name with us granted access,
a listed set of reusable components licensed to you perpetually, and a handover
obligation that means leaving is a process rather than a favour.
We publish this checklist knowing founders may use it on our own paperwork. That
is the point. If you want to see how ownership is written into a build before you
commit to anything, ask us how ownership works on our contracts.
Related guides
- How AI recommends MVP companies: what ChatGPT and AI Overviews actually pull from when someone asks who should build their MVP
- How to protect your app idea: the wider
picture of NDAs, trademarks and what you actually can and cannot protect. - MVP agency red flags: the warning signs that show
up before the contract does. - MVP development agency: how to choose the
partner you will be signing with. - Fixed price vs hourly: how the pricing model
changes the terms. - MVP outsourcing: the trade-offs of building outside
your own team. - MVP requirements document: the scope your
acceptance criteria should reference. - How much does it cost to build an MVP:
what you are agreeing to pay for.
Frequently asked questions
Who owns the code a developer writes for me?
By default, the developer does. Under 17 U.S.C. 201
copyright vests initially in the author, and an independent contractor is the
author of what they write. Paying for the work does not transfer copyright. You
need a signed agreement containing a present-tense assignment before ownership
moves to you.
Is a work-for-hire clause enough to own software?
Usually not on its own. Work made for hire covers employees, and covers
commissioned work only within nine categories listed in
17 U.S.C. 101. Software is not
one of them. A sound agreement uses work for hire where it applies and a present
assignment as a backstop for when it does not.
What is the difference between "hereby assigns" and "agrees to assign"?
"Hereby assigns" transfers ownership immediately on signature. "Agrees to assign"
or "shall assign" is only a promise to transfer later, so you own nothing until a
further document is signed. If the relationship ends badly, that promise has to be
enforced against someone with no reason to cooperate. Investors and acquirers
check this specific wording.
What is background IP in a development contract?
Background IP is pre-existing code the developer brings to your project, such as
internal libraries, boilerplate and tooling. It is not created for you, so it is
usually not assigned to you. You want it listed in a schedule and licensed to you
on perpetual, irrevocable, worldwide terms that survive the end of the contract.
Do I need an NDA with my MVP developer?
An NDA protects confidential information you share, which is a different job from
owning the code. It is worth having, but it is not a substitute for an IP
assignment, and founders routinely get the NDA and skip the assignment. See
how to protect your app idea.
Should the repository be in my account or the agency's?
Yours, with access granted to them. If the repository, domain, hosting or app
store accounts sit in the agency's name, a dispute or a slow handover can take
your product offline even when you clearly own the copyright. Create every account
in your own name from day one.
What should I ask for when leaving a development agency?
Full source code and commit history, all credentials and access, environment
configuration and deployment instructions, documentation, and an agreed number of
transition support hours. Get this written in as an exit assistance clause at the
start, because negotiating it at the end rarely goes well.
Sources and references
- 17 U.S.C. 201, Ownership of copyright:
copyright vests initially in the author - 17 U.S.C. 101, Definitions:
the work-made-for-hire definition and the nine commissioned categories - US Copyright Office, Circular 30: Works Made for Hire:
official guidance on when work for hire applies - Open Source Initiative, approved licences:
the canonical list of open-source licences
Method note: this guide describes US federal copyright rules, which do not apply
in every jurisdiction, and it addresses commercial practice rather than legal
strategy. Have a qualified lawyer review your actual agreement before signing.
