Why You Must Own Your Source Code From Day One (Not Just Your Product)

By Sharath8 min read
#Source Code#Founder Advice#IP#Legal#MVP Development

I've talked to founders who paid $40K to build an MVP they don't legally own. Not because they were scammed — because they signed a standard agency contract without reading it, and "standard" in the software agency industry often means the agency retains intellectual property rights until specific conditions are met. By the time they realized what happened, switching meant starting over. Here's what you need to know before you sign anything.

Table of Contents

What Source Code Ownership Actually Means

Owning your product and owning your source code are not the same thing.

You might have the exclusive right to use and sell your software product. But if the agency retains the underlying source code, they can resell the same codebase to your competitors, refuse to hand it over if you stop paying, or hold it hostage in a dispute.

Full source code ownership means:

  • You have the actual files — the complete codebase in a repository you control (your GitHub account, your organization)
  • You have an assignment of IP rights — a legal transfer of copyright from whoever wrote the code to you
  • No proprietary dependencies — the code doesn't rely on the agency's private packages, internal tools, or proprietary frameworks that only work with their systems
  • Documented and runnable — you can actually deploy and modify the code without the original developer's involvement

All four conditions need to be true. Most agency contracts only address the first one — access to the files — and quietly leave the other three unaddressed.

In most jurisdictions, copyright in software automatically belongs to the person or company that wrote it. This is the default. When a contractor or agency writes code for you, they own the copyright unless there's an explicit written agreement transferring it.

"Work for hire" doctrine applies to employees — software an employee writes in the scope of their employment belongs to the employer. Independent contractors and agencies don't fall under work-for-hire automatically. You need a specific IP assignment clause.

What this means: if your contract doesn't include a clear, explicit assignment of all intellectual property rights from the agency to you — for all work created under the engagement — you may not legally own the code, even if you paid for it.

This isn't hypothetical. IP disputes between founders and agencies happen. They're expensive, distracting, and often resolve in the agency's favor when the contract is silent on assignment.

What Happens When You Don't Own Your Code

Scenario 1: You want to switch agencies. You've been working with Agency A for a year. The relationship isn't working. You hire Agency B. Agency A's contract says they retain IP ownership of all code created under the engagement. Agency B looks at the codebase and says they can't continue it legally without an IP assignment from Agency A. You're stuck negotiating with someone you're trying to leave.

Scenario 2: You need a new developer. You bring on a CTO or senior engineer. They look at the codebase and discover it uses the agency's proprietary internal framework. The code runs, but it's effectively locked into that agency's ecosystem. Modifying it requires either going back to them or rewriting it from scratch.

Scenario 3: Due diligence in a funding round. Investors do technical due diligence. Their lawyers look at your contracts and find that IP ownership is ambiguous. The deal slows down while you sort it out. In a bridge round with a runway deadline, this is a serious problem.

Scenario 4: Agency goes under. The agency that built your product shuts down. Their contracts, IP, and assets go into bankruptcy proceedings. Your codebase becomes entangled in that process. You're still running on their servers when this happens because they hosted it.

The 5 Contract Clauses That Protect You

1. IP Assignment "Upon receipt of all payments due, Agency assigns to Client all right, title, and interest in and to all intellectual property created under this agreement, including all source code, documentation, and related materials."

Look for: "assigns" not "licenses." Licenses are revocable. Assignments are permanent transfers.

2. No Proprietary Dependencies "All deliverables shall be built using open-source libraries and publicly available tools. Agency shall not incorporate any proprietary code, internal frameworks, or third-party software that requires ongoing licensing agreements with Agency."

This prevents the locked-ecosystem trap.

3. Repository Access from Day One "Agency shall provide Client with access to the project repository from the start of development. Client shall have read and write access to all branches."

Don't wait until project completion for repository access. You should be able to see the code being written as it's written.

4. No Retention of Copies "Upon assignment, Agency shall not retain copies of Client's source code, proprietary data, or confidential information beyond [X days] following project completion, except as required by applicable law."

Agencies with your code can use it as a "template" for other clients. This clause prevents that.

5. Survival of Assignment "The IP assignment in Section X shall survive termination of this agreement for any reason, including non-payment disputes."

Without this clause, some contracts are structured so that if you have a payment dispute, the IP assignment is retroactively voided. You paid for the code; you should own it even if there's a billing disagreement.

Proprietary Dependencies: The Hidden Trap

The proprietary dependency issue deserves its own section because it's the most technically sophisticated way founders get trapped.

Agencies sometimes build products on top of their own internal libraries, authentication wrappers, or deployment systems. On the surface, your codebase looks normal. But buried inside are imports that reference private packages hosted in the agency's npm registry, or API calls to internal services the agency runs.

The code is yours on paper. But it doesn't actually run without the agency's private infrastructure.

Signs of proprietary dependencies:

  • Private npm packages that aren't on the public registry
  • References to internal APIs with undocumented endpoints
  • Authentication or licensing calls that phone home to the agency
  • Deployment configurations that only work with the agency's hosting setup

Ask specifically: "Is there any code in this project that requires your private packages, internal services, or proprietary tools to run?" A good agency will say no and show you the package.json. An agency with something to hide will deflect.

What "Full Source Code" Includes

Full source code ownership means you have:

  • All application code — frontend, backend, API routes, business logic
  • All configuration files — environment templates, deployment configs, CI/CD pipelines
  • Database migrations — the files that create and modify your database schema
  • Infrastructure as code — Terraform files, serverless configs, if applicable
  • Documentation — README, API documentation, deployment instructions sufficient to run the project without the original developer
  • Build scripts — anything required to install dependencies and run the project locally

Missing any of these can create practical ownership gaps even if you have legal ownership. A codebase with no documentation and no database migrations is very difficult to hand to a new developer.

How V12 Labs Handles This

At V12 Labs, we push everything to a GitHub repository in your organization from day one. You have admin access before we write the first line of code.

We use open-source libraries exclusively — everything is listed in package.json, publicly available, no proprietary dependencies. When we finish the project, we don't retain copies.

Our contract includes explicit IP assignment language covering all deliverables. We're happy to share our standard contract terms before you sign, so you can review them with a lawyer if you want.

The reason we're this explicit about it: founder trust. If you can't verify that you own what you paid for, everything else we say about quality and speed doesn't matter. Code you don't own isn't an asset — it's a liability.

Questions to Ask Before Signing

Before you sign with any agency, ask these directly:

  1. "Who owns the IP in all code written under this engagement, and can I see that clause in the contract?"
  2. "Will I have GitHub repository access from Day 1, or only upon project completion?"
  3. "Does any part of this codebase rely on your private packages or internal services?"
  4. "What happens to IP ownership if we have a payment dispute?"
  5. "Can I hire another developer to continue this codebase after our engagement ends?"

A reputable agency will answer all five cleanly and without hesitation. Any deflection, vagueness, or "we'll work that out later" is a red flag.

Ready to Build?

At V12 Labs, code ownership isn't a feature we charge extra for — it's the baseline. Your code, your repo, your IP, from the first commit.

$6K flat fee, 15-day delivery. Book a discovery call at v12labs.io and we'll send you our standard contract terms before you decide anything.

← Back to Blog