Can someone own your code... just by using it?

Lately, I’ve been working with more and more development agencies. A pattern keeps showing up. Clients love the work.

They want more involvement. So the agency shares access. A little here. A little there.

No paperwork. No boundaries. Just “temporary access.” And for a while, everything’s fine - until it’s not.

The Client Has the Code. Do They Own It?

Let me walk you through a real conversation I had with a dev agency.

They were mid-way through a high-ticket project. The relationship with the client was solid. Weekly calls were happening. Invoices were being paid on time.

Then one day, the client asked to “review the code.” The agency didn’t think twice.

They granted access. Just for review. No contract changes. No license updates.

Six months later? The client ghosted. Then launched their own product. Based entirely on the same codebase

The kicker? The original agency had:

• No clause about code ownership

• No definition of access or its limits

• No formal handover or IP licensing

And the client? They claimed they “always had rights to use the code” - because they had access.

This Is Where Assumptions Become Expensive

The contract never explained what access meant. It didn’t say:

• Who owned the IP?

• What could be done with the code

• Whether access was temporary?

• Whether reuse or distribution was allowed?

So the client filled in the blanks. And guess who ended up losing time, money, and months of hard work?

When Contracts Are Silent, Assumptions Get Loud

In legal terms, if something isn’t defined, courts (and clients) interpret it.

And most interpretations don’t favour the person who shared the work without clear rules.

Generosity is good. But it needs boundaries.

Here’s What I Recommend Every Dev Agency Do

Whether you’re building SaaS, apps, or integrations - put these in your contracts:

1. Define Code Ownership Explicitly

“Developer retains all intellectual property unless explicitly transferred in writing.”

This makes it clear that access doesn’t mean ownership.

2. Limit Client Access with Purpose

“Client access is granted for review only. No copying, reuse, or distribution is permitted without written consent.”

This turns the access into a loan - not a handover.

3. Use Temporary, Revocable Licenses

“Review access expires after 14 days unless extended. License is non-transferable, non-commercial, and limited to internal use.”

Now the client knows it’s short-term and can’t be misused.

4. If You’re Handing Over Ownership, Be Specific

“Upon full payment, ownership of Modules A, B, and C transfers to the Client. All other modules remain the property of the Developer.”

Break it down by feature, not vague categories like “the codebase.” That’s where trouble hides.

TL;DR - Access Without Contracts Is a Trap

Here's a quick summary of everything:

• Granting access ≠ giving away rights

• Without clear IP clauses, you’re exposed.

• Assumptions about “review access” often backfire

• You must separate access from ownership on paper.

Final Thought: Silence Isn’t Safety

You can build great client relationships. You can be generous. You can share your work for review.

But you must do it with terms. Because in tech, the line between access and ownership isn’t drawn by trust. It’s drawn by contracts.