Who Owns the Code When You Pay a Developer to Build It?

You paid for it. Twenty thousand, forty, whatever the number was. The scheduling system works, the crew uses it every day, and the invoices go out on their own now. Then one morning you want to change something, and the developer stops answering email. And you find out you can't log in to the hosting account to hire someone else, because it was never yours.

The question of who owns the code when you pay a developer to build software has a messier answer than most owners expect. A contract can say one thing. The accounts say another, and the accounts usually win.

By the time you finish reading, you'll know what to look at on your own setup, and what to ask before you sign with anybody new.

Paying a developer to build your software does not mean you own it

Money changed hands. Work got delivered. That covers the build. It says nothing about who holds the keys to the thing that got built.

Software isn't a truck. When you buy a truck, the title comes with it and your name goes on the registration. Custom software is a pile of code sitting on servers you rent, talking to services you pay for, and every one of those pieces has an account behind it with somebody's name on it. If that name is the developer's, then the developer controls the thing, no matter who wrote the check.

Plenty of contracts say the client owns the work product. That language is worth having. It's also worth very little on a Tuesday morning when you need to move your system to a new shop and the person who holds the hosting login has gone quiet. You'd be chasing a lawyer to get access to something you already paid for. Most owners skip it. They eat the loss and start over.

The thing that actually settles ownership is boring and checkable. Whose name is on the hosting account. Whose card gets billed every month. Who can add a new developer to the code repository without asking anyone.

That's the whole test. You can run it today on whatever you already have, and you can run it on any developer before you sign with them. It takes about ten minutes, and it tells you more than any paragraph in a contract will.

A contract can say you own it; the accounts settle it

An invoice marked paid proves you bought something. It doesn't prove what you bought.

Say the hosting account was opened with a developer's email and a developer's credit card. That account is theirs. The database sitting under it is theirs. The app store listing with your company name on it is theirs. You paid for the work, and a signed contract may say the finished software belongs to you, but every door into it opens with somebody else's key. Getting those doors transferred means asking nicely, and hoping the answer is yes.

Now flip it. The hosting account was opened in your business name, with your card on file. Same for the database, the texting account, the payment processor. You can log into every one of them tonight without calling anybody. If the developer disappeared on Friday, you could hand a new one the logins on Monday and keep going.

Same build. Same money. Completely different position to be in.

So the question of who owns the code when you pay a developer to build your software gets answered in an account settings page, not in a paragraph. Any developer can tell you the code is yours. The ones worth hiring open each account in the client's name from day one. A contract is worth having. It's the cleanup plan for when things go wrong. The account names are what keep you from needing one.

Your job system runs on accounts a freelancer can open in their name

Most owners picture one account. There are usually five or six, and each one can be opened in the wrong name.

• Hosting. The server or platform where the app actually runs. If this lapses or gets locked, the app goes dark.
• The database. Where your customers, jobs, quotes and invoices live. This is your business history. Losing access to it is worse than losing the app.
• App store accounts. If your crew uses a phone app, there's an Apple developer account and a Google Play account behind it. Apps get published under whoever owns those. Moving a published app to a different account later is slow and annoying.
• Payments. Stripe, Square, whatever processes the card. Money from your jobs flows through an account that should have your business name and your bank on it.
• SMS. The number and account that sends your missed-call texts and invoice reminders. Phone numbers are tied to the account that registered them.
• Domain and email. Often forgotten until renewal day.

Any one of those opened by a developer under their own login is a point where you have to ask permission. On its own, that's a small hit. Six of them together is a different situation.

Here's a thing worth doing this week. Open a notes file and write down each piece of software your office touches, then write the email address the account is registered to. If you can't name the email, that account isn't yours yet. That list is also the first thing a good client-side handover starts with, and it takes about twenty minutes to build.

How we open every account in the client's name

When we build a system, the first work isn't code. It's accounts.

Hosting goes in the client's name. The database, the app store listings, the payment processor, the SMS provider that sends the missed-call texts — same thing. Each one is opened under the owner's email, with the owner's card on file. We sit inside those accounts as a user with access. We don't sit on top of them as the owner.

That means a developer at our shop can deploy, fix, and ship. It also means that if the relationship ends on a Friday, nothing breaks on Monday. You change a password or remove a user, and the system keeps running on accounts that were always yours.

Owners sometimes push back on this part, because it's easier to hand a card to the builder once and never think about it. It is easier. It's also the exact thing that costs people later. Putting your own card on the hosting account takes a few minutes per account during the build, and you'll feel the benefit the first time you want a second opinion from another developer.

The exact set of accounts depends on what the system does. A crew that takes card payments in the field needs a payment processor. A crew that only texts and invoices by email doesn't.

Ask any builder to list the accounts their work will touch and write that list into the contract before anyone starts. Not legal language. Just a list, with a name next to each one.

Your source code should live in a repo you can log into

Accounts are half of it. The other half is the source code — the actual files that make your system work.

Code lives in a repository, usually on GitHub. Whoever owns that GitHub account controls the code. They can add people, remove people, and decide who gets a copy. If your developer holds the repo under their own account, you don't have the thing you paid for. You have a working app and someone else's permission to keep using it.

So we open a GitHub account in the client's name, the same way we open hosting. The repo sits there. We get added as a collaborator and we push our work to it. If the relationship ends tomorrow, we get removed and the code stays exactly where it was.

That's the point of it. You should be able to hire a different developer next month, hand them the login, and have them start reading your code that afternoon. No email to us. No waiting on a transfer. No invoice for "export."

It also protects you from boring problems. Developers get sick. Small shops close. If the only copy of your system lives in an account you can't reach, a bad week for someone else becomes a bad month for you.

Ask to see the repo. Log into it yourself. If you can open your own code in a browser and read the commit history, you own it in the way that matters.

What it looks like when a developer keeps the keys instead

Nothing looks wrong at first. The site is up, the app works, the invoices go out. Then you want a change the developer doesn't want to make, or you want a second opinion, and you find out the hosting account is in their name, the card on file is theirs, and the repo lives in an agency account you've never seen.

Now you're not a client. You're a tenant.

Chris's view on this is blunt: a freelancer or agency that opens accounts in its own name and uses that to lock a shop in is doing something close to criminal. Being the opposite of that is the reason First-Rate Tech Corp exists.

The practical effect is simple. You can't leave. You can fire the developer, but the system goes with them, or it stays dark until someone pays whatever is asked to release it. Your customer records, your job history, your phone number routing, your payment connections — all of it sits behind logins you don't have. The next developer can't quote the work because they can't see the work.

Some of this is sloppiness rather than malice. It's faster to spin up hosting on an account someone already has than to sit with an owner and set up a new one. The result is the same either way.

If you're in this spot now, start asking for transfers in writing, one account at a time, beginning with hosting and your domain.

Three questions to ask before you sign with any developer

Ask these out loud, in the meeting, before money changes hands. A good freelancer or agency answers them in about ten seconds without getting defensive.

Whose name is on the hosting account? Not "we'll host it for you." Who is the account holder of record on the server, the database, the domain registrar? If the answer is the agency, ask why, and ask what it takes to put it in your name instead. The answer should be "we'll set it up in yours."

Whose card is on file? This one is the tell. Billing follows ownership almost everywhere. If the developer's card pays for hosting and SMS and the app store listing, the vendor considers the developer the customer, and you're a line item on someone else's bill. When your card pays, you can log in, you can see what things cost, and you can keep the lights on if the relationship ends tomorrow.

Who holds the repo? The source code has to live somewhere. Ask which GitHub account the repository sits under, and whether you, the client, have the owner role on that account. Not a collaborator invite. Owner.

You'll learn more from how the question lands than from the words. An honest shop says "yours, yours, and yours," then walks you through setting the accounts up on day one.

Get the answers in the contract if you can. But the contract matters less than the accounts themselves. A signed page saying you own the work doesn't help much when you can't log in to the thing you own.

What "work made for hire" means in plain terms

Here's the part that surprises owners: under U.S. copyright, the person who writes the code usually owns it the moment it's written. That's the default ownership rule. Paying the invoice doesn't move it.

There's an exception called work made for hire. When an employee writes software as part of their job, the company owns it automatically. Your office manager builds a spreadsheet on the clock, that's yours. But a developer you hire from outside is almost always an independent contractor, not an employee, and the work-made-for-hire rule doesn't apply to them the same way. For a contractor, ownership of the intellectual property has to be assigned to you in writing. If nobody wrote it down, the developer may still hold the copyright on code you paid for in full.

We're not attorneys and this isn't legal advice. Have a lawyer read any agreement before you sign it, especially the part about who owns what.

What we will say is this: the paperwork and the accounts are two separate problems, and owners tend to fix only the first one. A clean IP assignment clause is worth having. It's also a piece of paper. If the hosting login, the payment account and the repo are all in somebody else's name, you'd be enforcing that clause from the outside, with your scheduling system running on hardware you can't reach.

Fix both. The writing, and the account names.

Signs you don't own the accounts or the open source code inside

Log into your hosting provider. If you can't, because you've never had a login, that's the first one.

A few more to check this week:

• The bill doesn't come to you. Hosting, SMS, the app store developer account — if those charges show up on an agency invoice as a line item instead of on your card statement, the accounts aren't yours.
• Password resets go somewhere else. Try one. If the email lands in a freelancer's inbox, so does control.
• Your app looks like three other apps. Reused templates aren't a problem on their own. But ask what's underneath. Most software is built on open source and third-party components, and each one carries a license with terms. Some are fine for commercial use forever. Some aren't. You want a written list of the open source and third-party components in there.
• Nobody will name who wrote it. Subcontracted and offshore work is common and often good. Undisclosed subcontracting is different. If a developer you never hired wrote the code, your agency may not hold the intellectual property it promised to hand you.

Ask for the account list and the component list in the same email. An honest shop sends both back. A vague answer is the answer.

Who owns the code when you pay a developer to build software

Who actually owns the code? Whoever the written agreement says owns it, backed up by whose name is on the accounts. Copyright in software usually starts with the person who wrote it, so a developer can hold the rights to your system until a signed agreement moves them to you. That transfer should be on paper before the build starts. Then check that the hosting, repo and payment accounts match the name on the agreement. Paper and accounts should tell the same story.

Who owns code written by AI? Treat it like any other code the developer hands you. Most shops use AI assistants now, the same way they use open source libraries and prior work. What matters is the agreement with the developer and who controls the accounts the source code lives in. US copyright law gives thin protection to material generated without human authorship, which is one more reason to care about possession and access rather than only about intellectual property paperwork. If you hold the repo and the hosting, you can keep working no matter who wrote which line.

If you want a second set of eyes on your setup, book a New Project Consultation.