Who Owns Your Code When the Contract Ends? The Clause Most SMBs Skip

The question nobody asks until it's too late

A business owner calls a new developer to add a feature to a system their last agency built two years ago. The new developer asks for the source code repository. There isn't one — or rather, there is, but it lives in the old agency's GitHub organization, under their account, and they're not returning calls. The client paid tens of thousands of dollars for software they cannot open, cannot move, and cannot hand to anyone else.

This isn't a scam story. It's what happens by default when a contract never specifies who owns what. Most SMBs, schools, and institutions negotiate hard on price and timeline and never read the three sentences that actually determine whether they own their software or are renting it indefinitely from whoever built it.

"Work product" is not the same as "ownership"

Many service agreements say the client owns the "work product" or "deliverables." That sounds like full ownership. It often isn't.

• Work-for-hire vs. license. Some contracts grant the client a license to use the software, not a transfer of the underlying intellectual property. A license can usually be revoked, limited to specific use cases, or tied to continued payment. Outright ownership (a work-for-hire or assignment clause) transfers the copyright itself — the client can modify it, resell it, or hand it to a competitor's developer with no further permission needed.
• The repository, not just the code. Owning "the code" means nothing if it sits in a repository you don't control. Ask explicitly: whose GitHub or GitLab organization does this live in, and do I have admin access to it — not read access, not a zip file emailed at the end, but the actual repository with full commit history.
• Credentials and infrastructure. Domain registrar, hosting account, database, DNS, third-party API keys — these are usually separate from the code itself and separately forgettable. A system can be fully owned on paper and still functionally held hostage if the vendor controls the hosting account and the login.

Why vendors sometimes prefer license over ownership

It's worth naming the incentive honestly: a vendor who retains ownership, or who builds on a proprietary framework only they can maintain, has a client who can't leave. That's not automatically bad faith — some agencies genuinely believe their framework is the better technical choice, and reusable internal tooling is a legitimate part of how a studio stays efficient. But it creates a structural conflict: the vendor's interest in being easy to leave is weaker than the client's interest in being able to leave. A client who doesn't ask about ownership is trusting the vendor to resolve that conflict in the client's favor, with nothing in writing.

The tell is usually in the stack, not the contract language. A system built on a vendor's own closed, unpublished framework — one no other developer can pick up without being trained on it by that same vendor — is a lock-in by architecture even if the IP clause looks fine on paper. Standard, documented technology (a common language, a common framework, a readable codebase) is portable between developers. A proprietary black box is not, no matter who legally owns the copyright.

What to put in the contract before you sign

A short list that costs nothing to ask for and saves real money later:

1. Explicit IP assignment. "Client owns all right, title, and interest in the deliverables upon full payment" — not "client receives a license to use."
2. Repository access from day one, not at project end. You should have admin rights to the actual repo while development is happening, not a promised handoff later.
3. Your own hosting, domain, and database accounts, with the vendor added as a collaborator — never the reverse.
4. A named, standard technology stack in the proposal, so you can verify it's not a proprietary framework only that vendor can service.
5. A documented handoff deliverable: a README, environment setup instructions, and a list of all third-party services and keys the system depends on. If a vendor can't produce this in a day, it probably doesn't exist, which is itself information.

None of this is adversarial. A vendor confident in their own value has no reason to resist any of these five points — they make the relationship easier to leave and, not coincidentally, easier to stay in voluntarily, because the client isn't staying out of fear of the alternative.

The takeaway

Ownership isn't the line item in the invoice that says "deliverable: 1 dashboard." It's the IP assignment clause, the repository access, and the hosting credentials — three things that cost a vendor nothing to hand over honestly and cost a client everything to discover missing after the relationship ends. Ask for all three before signing, not after you need to leave.