Who Owns Your Code?

What Every Non-Technical Founder Needs to Know Before They Hire

You find a developer you trust, or an agency that seems solid ;). You talk through the idea, agree on a rough scope, and feel good about moving forward. Then you sign the contract and start building.

What most founders don’t do, because they don’t know they should, is read the ownership section.

This is the section that determines who actually holds the rights to what gets built, where it lives, and what happens to your product if the relationship ends before you expect it to.

This isn’t a story about bad developers. Most of the founders who’ve sat across from us with ownership problems were working with perfectly competent people. The problem wasn’t malice. It was a contract that nobody examined carefully enough, and a conversation that never happened.

Here’s what you need to understand before you sign, and what to do if you’re already mid-build.

The Three Things Founders Confuse

When founders say “I own my code,” they usually mean one of three different things — and only one of them might actually be true.

IP Ownership

Intellectual property ownership is the legal layer. It determines who holds the rights to the code as a creative work; the same category as writing, music, or design.

In most work-for-hire arrangements, the client owns the IP. But most isn’t all, and the language matters more than the intention. A contract that assigns IP “upon final payment” leaves you without ownership rights while the work is in progress. A contract that doesn’t address IP at all leaves you in whatever position a court decides is default, which varies by jurisdiction and contractor type.

Ownership of the IP until final payment is industry standard, so dev firms or agencies with this language aren’t trying to pull a fast one. They’re trying to ensure bad actors on the founder side from taking advantage of their dev partners.

Before you sign: find the IP clause, read it, and see where and at what point it assigns ownership to you throughout the project.

Repository Control

The repository is where the code physically lives, and serves as the version-controlled history of everything that’s been built. This is separate from IP ownership because you can legally own something you don’t control.

If your developer creates the repository under their GitHub account or their organization, they’re the administrator. They can control access, visibility, and what happens to it. If they leave, if the relationship sours, or if they simply get busy, your code is sitting in an account you don’t manage.

The way to avoid this is simple and, for many founders, non-negotiable: the repository should be created under an account you own, from day one. Your developer gets collaborator access. Not the other way around.

Before you sign: ask explicitly where the repository will be created. If the answer is anything other than your own GitHub (or equivalent) organization, ask why, and push back if you aren’t aligned with their reasoning.

Infrastructure Access

Your product runs on servers. Someone pays for them, manages them, and has the credentials to deploy updates, roll back changes, or shut them down.

If that someone is your developer, you have an operational dependency that’s invisible until you need it. Deployment access, cloud provider logins, domain management, API keys—any of these managed exclusively by a contractor represents a single point of failure.

This one is easy to let slide during a project because it’s logistically convenient to let developers manage their own environments. The time it costs you is minimal. The exposure it creates is not.

Before you sign,: if you are concerned, it is best to establish that billing accounts, deployment environments, and critical credentials will be under your control, with access granted to your developer, not the other way around.

The Questions to Ask Before You Sign

You don’t need to understand code to protect yourself here. These are structural questions. Any developer who’s done this before will expect them.

• “Who owns the IP while the project is in progress, and is that stated in the contract?”
• “Where will the repository be created, and will I have full admin access?”
• “Which billing accounts will the deployment infrastructure sit under?”
• “What does handoff look like when this project ends, specifically, what documentation is included?”
• “If you were unavailable for two weeks with no notice, what happens to the project?”

These aren’t adversarial. Framed well, they’re a reasonable due diligence conversation that a prepared founder has and a seasoned developer expects. Defensiveness or vagueness in response to any of these is worth noting before you sign, not after.

The Single Point of Failure Problem

Software teams measure something called the bus factor: how many people would need to become unavailable before a project can’t continue. A factor of one means a single person’s absence could stop everything.

Most early-stage builds have a factor of one. That’s usually fine when the relationship is working. It becomes a serious problem when, for example, a developer gets a full-time offer, takes another client, gets sick, or simply stops responding.

The antidote isn’t more developers. It’s about understanding documentation, repository ownership, and infrastructure access so someone else can pick up where the first person left off without starting from scratch, if the need arises.

A developer who documents as they go, explains their architectural decisions, and sets up infrastructure under your accounts isn’t just being thorough. They’re giving you options. That’s what a good development partner does.

What to Do If You’re Already Mid-Build

If you’re reading this and already in a development engagement that doesn’t meet these standards, you’re not necessarily in trouble, but you might need to move quickly on a few things.

• First, clarify repository ownership. Ask your developer to transfer the repository to an account you control, or create a new one and migrate. This is a minor logistical step for anyone who knows what they’re doing. Resistance to this request tells you something important.
• Second, audit your infrastructure access. Make a list of every service your product relies on (i.e., hosting, databases, authentication providers, third-party APIs) and verify you have credentials for each. Start getting access transferred to accounts in your name.
• Third, ask for documentation of what’s been built so far. Not a comprehensive manual, but a readable summary of architectural decisions, technology choices, and what another developer would need to know to continue the work. This is a reasonable ask at any stage of a project.
• Fourth, check your contract’s IP clause. If it’s non-existent, ambiguous, or conditional, talk to a lawyer about whether a short addendum would be appropriate. The cost of that conversation is small relative to the risk.

The Contract Terms That Actually Matter

If you’re negotiating a developer contract from scratch, here’s what to make sure is in it:

• Clear IP assignment throughout the project, or, just as reasonably, contingent on final payment. You might want to own what’s being built as it’s being built, but that might not be a reasonable request from a dev POV.
• Repository ownership specified. Your GitHub organization, your admin access and the developer gets collaborator or maintainer access.
• Documentation as a deliverable. Not an afterthought. Define what it includes: architectural decisions, deployment instructions, third-party service inventory, what a new developer would need to continue the work.
• Access transfer at project completion. A specific list of what gets handed over when the engagement ends: repository access, deployment credentials, API keys, domain management.

These aren’t aggressive terms. They’re standard for a well-run engagement. A developer who pushes back on any of them wihtout a justifiable reason, is showing you a little bit about how they work (which is useful information before you’ve paid a deposit).

When to Bring in Outside Help

There are moments in this process where a second perspective is worth more than any document:

• When you have a proposal in hand and can’t tell if the terms are normal.
• When you’re mid-build, and something feels off, but you can’t articulate why.
• When a developer has gone quiet, and you’re trying to understand what you actually have access to.
• When you’re evaluating two or three developers and don’t have a technical framework for comparison.

This is what a product strategy consultation is for. Not to review code, but to help you understand what you’re building, how you’re building it, where you fit into all of this, how to ask the right questions, and make decisions with more clarity than you’d have alone.

If you’re beginning to create a digital product, our Product Architecture roadmap gives you clarity on everything to expect, or how to approach it, before anything even has the chance of becoming a crisis. → Book time with us today

The Short Version

You don’t need to understand code to protect your ownership of it. You need to know what to ask, what good answers look like, and what to do if something isn’t right.

IP ownership, repository control, and infrastructure access are three different things. Most founders assume they have all three. Not all of them do.

Ask before you sign. Document before you launch. Transfer before the relationship ends.

These conversations are much easier to have before you need them.