Who Should Own the GitHub Repository? A Critical Mistake Founders Make

Holding the Title Is Not the Same As Holding the Keys

I was speaking with a founder recently who wasn’t happy with the performance of his software vendor. He had concerns about any risks he might have if he ended the relationship.

He felt confident that he was in control of the IP because he had that covered in his services contract. I said that’s good, but it’s not enough.

He needed help understanding why.

I knew that his source code lived in a repository that his vendor owned.

I explained it like this: You probably have the title to the car you drove here today. You are the legal owner of the car. Now you decide to give the car and keys to someone else, and they decide to keep it stored in their garage. You are trusting that they’ll give you the car back when you ask for it. Maybe they will, maybe they won’t. You still own it, but now might have to resort to litigation to try to recover your car. It’s essentially of no value to you anymore because you can’t use it.

You might own it.

But can you drive it?

And if you can’t drive it, does it have any value to you?

I’ve had these conversations before, and I’ll have them again.

Founders and business owners don’t always understand what it means to own the accounts, the database, and other critical infrastructure.

Contracts Protect You. Control Empowers You.

Contracts are essential. They define ownership, expectations, and recourse if things go wrong.

But contracts don’t:

• Give you admin access

• Guarantee immediate availability

• Prevent operational disruption

Control lives in systems and permissions, not just language in a PDF.

If you have to ask someone else for access to your own production systems, you don’t truly control them.

Own the Accounts. Grant the Access.

As a founder or business owner:

You create and own the core accounts.

You grant access to vendors and contractors.

Not the other way around.

That includes:

• Source control (GitHub, GitLab, Bitbucket)

• Cloud hosting (Amazon Web Services, Google Cloud, Microsoft Azure)

• Domain names (Network Solutions, GoDaddy, Cloudflare Registrar)

• DNS (Google Public DNS, OpenDNS, Cloudflare)

• Email services

• Payment processors

• Analytics

• Third-party APIs

If it runs your business, it should be in your name, billed to you, and controlled by you.

No exceptions.

Why This Matters More Than You Think

When the vendor owns the infrastructure: offboarding becomes messy, leverage shifts away from you, and continuity depends on goodwill.

Even if everyone is acting in good faith, structural dependency creates fragility.

And fragility shows up at the worst possible times — funding rounds, acquisitions, vendor disputes, or leadership changes.

A Real-World Example: When You Don’t Own the Account

I recently worked with a client whose address validation suddenly stopped working.

The application depended on an API from USPS. The original developer had created and managed that account.

At some point, USPS deprecated the API and required users to migrate. My client never received any notification because the account wasn’t in their name.

One day, the feature just stopped working.

We were able to fix it quickly, but the outage could have been avoided entirely if the account had been owned and managed by the business.

This is exactly how loss of control can show up in practice — not as a legal issue, but as an unexpected operational failure.

The Simple Control Checklist

If you’re building or relying on existing software, ask yourself:

• Do we own the repository?

• Do we have admin access to our hosting environment?

• Is the domain registered under our name?

• Do we control DNS?

• Are core services billed directly to us?

• Could we replace our current vendor tomorrow if we had to?

If any of those answers is “no,” you don’t fully control your technology stack — even if your contract says you own the IP.

The least expensive time to fix these problems is right now. The longer you ignore it, the more complex things become and the harder it will be to transition.

Final Thoughts

These issues don’t usually show up as legal disputes.

They show up when something breaks and you don’t know why. Or when a vendor disappears. Or when an API shuts down and no one told you.

That’s when the difference between ownership and control becomes very real.

Ownership is legal.

Control is operational.

Both matter — but only one determines whether you can move fast, pivot, or recover when something goes wrong.

Make sure you’re not just holding the title.

Make sure you’re holding the keys.