It is the question nobody asks at the right time. It comes up at the end, when the relationship has soured or you want a different team to take over the work. By then it is settled: whatever the contract says is what you have.
And what most contracts say, on this point, is nothing.
The default rule runs against the buyer
Paying for software does not make you its owner.
Under US copyright law, copyright vests in the author of the work. If an employee writes code within the scope of their employment, the employer is treated as the author and owns it. That is the work made for hire doctrine, and for employees it works cleanly.
For an independent contractor, it does not apply the same way. The statute treats a commissioned work as made for hire only when it falls into one of nine enumerated categories and the parties agree in a signed writing. Those categories cover things like contributions to a collective work, translations, instructional texts and audiovisual components. Software is not among them.
The practical consequence is blunt: writing “work made for hire” into a development agreement does not, on its own, transfer ownership of software. That is why carefully drafted agreements add an express assignment as well, precisely so the clause does not depend on a doctrine that may not reach the work.
Absent any of that, you have paid for a deliverable and you hold a binary. What you may do with it will be argued about on the day it matters. Some courts have found an implied non-exclusive licence in these situations, which is thin comfort: an implied licence is what you get when nobody wrote down what you bought.
None of the above is legal advice, and the fact patterns matter. It is, however, the default that a great many buyers assume runs the other way.
The four levels, worst to best
Level 1: the agreement is silent. The most common case with small vendors, and rarely malicious. There is a quote template nobody has ever had reviewed. The effect is the same as bad faith: nothing has been transferred to you.
Level 2: a licence to use. You are permitted to use the software. Sometimes “in connection with your business”, sometimes “for the term of this agreement”. You can run it. You may not be able to have a third party modify it, or deploy it elsewhere. This is the wording that most resembles ownership without being it, and it is the most common in agreements drafted competently from the vendor’s side.
Level 3: a partial assignment. Code specific to your project comes to you; the vendor’s reusable framework stays theirs under licence. This is often the honest description of reality, and it is perfectly acceptable provided the boundary is written down. A vendor who built a toolkit at their own expense across ten engagements cannot assign it to you without giving away their business. What is not acceptable is discovering where that line falls on the day you leave.
Level 4: full assignment on delivery and payment in full. Source code, content produced, credentials to third-party services. That is what we put in our agreements, and it is not generosity: it is the logical counterpart of a fixed fee. If we sell a result rather than time, the result is yours.
The four lines to check before signing
None of this requires a law degree. It requires searching the document for words.
1. The word “assign” or “assignment”, not only “licence” or “right to use”. Search for it literally. If it is absent, ownership has not moved, however warm the commercial relationship.
2. What triggers the assignment. “On delivery and payment in full” is healthy wording. It protects both sides: the vendor has not assigned unpaid work, and you have not paid for unassigned work.
3. The scope of what is assigned. The code, but also: deployment scripts, technical documentation, test data, design files, and credentials to every third-party service opened for your project. Source code without its deployment scripts is a jigsaw with no box. This is the most common omission and the most disabling in practice.
4. A warranty against third-party claims. The vendor warrants that the deliverables do not infringe anyone else’s rights. That clause, rather than any argument about how the code was produced, is what protects you if a component was pulled in under an incompatible licence.
The question that reveals everything, and takes a minute
Ask this out loud, before signing:
“If in two years I want a different team to take over, what do you hand me, and how long does it take?”
The answers sort themselves.
A vendor who says “the repository, the runbooks, the credentials, and we allow a few days for handover” has done this before and organized it. A vendor who says “no problem, we’re very open” with no detail has never done it. A vendor made uncomfortable by the question has just given you the most useful information in the meeting.
The question is not a trap. It establishes whether reversibility exists as a process or as an intention.
What we put in our agreements, and why
On delivery and payment in full, the client owns the source code written for their project, the content produced for it, and the credentials to the third-party tools involved. We keep attribution for the work and the ability to name the client as a reference unless we agree otherwise. The client can take over or move to another provider at any point, and a documented handover is provided if the relationship ends.
The reason is structural rather than ethical. A business model resting on client dependency pushes you to ship code nobody else can pick up. That is not an intention, it is a gradient. Assigning everything removes the gradient: the only way to keep a client is for them to want to come back.
Measured in July 2026, across roughly thirty engagements delivered since 2019: no client has ever had to call us back on an emergency after handover. That is a first-party figure, so treat it as a claim we are accountable for rather than an audited fact. It is also the one we would most want raised in a reference call.
Further reading
- Custom software development : the fixed-fee format, with the assignment written in
- Post-launch support : optional, and it never recreates a dependency
- Fractional CTO : when the decision itself needs someone senior on your side
- Case studies : including one where the source code was handed to a government agency
- Build or buy: the calculation almost nobody runs : before the ownership question, the build question