# Who Owns the Code When You Hire a Software Developer?

If you pay someone to build your software, you may not own it by default. Here is how code ownership, hosting accounts and handover work, and what to put in writing.

You pay a developer to build your software, so you own it. That seems obvious, and it is often wrong. In many countries, including the US and most of Europe, the person who writes code is the legal author of it. Paying for the work does not move that ownership to you. A written agreement does.

This post covers what to check before you sign, and what a clean handover looks like. It is general information, not legal advice. If the project is large, a short review by a lawyer is cheap compared with finding out later that you do not control your own product.

## Who owns custom code by default?

Without a written agreement, the developer usually keeps the copyright, and you get a license to use what they built. Sometimes that license is broad. Sometimes it is vague, and a vague license is where disputes start.

"Work for hire" is often quoted as the fix, but it does not work the way many people assume. In the US it only applies automatically to employees, and to a short list of contractor work types that software often does not fit. For contractors, the safe route is an explicit clause that assigns the intellectual property to you once the work is paid for.

## What a good ownership clause says

Look for these points in the contract or statement of work:

- The code, designs and documentation created for you are assigned to you, not just licensed.
- The assignment takes effect on payment, or on each milestone's payment.
- The developer lists any third-party or open-source code they use and the license each one carries.
- If they reuse their own tools across clients, you get a license to anything of theirs that your product depends on.

If any of these are missing, ask. A developer who works this way regularly will answer in one email.

## Code is only half of ownership

The code is only part of what you need to keep your product running. The rest sits in accounts, and this is where small businesses get stuck most often:

- The code repository (GitHub or similar)
- Hosting and cloud accounts
- The domain name
- App store developer accounts
- Third-party services such as payments, email, analytics and AI providers
- Databases and backups

The safe setup is simple. Every account is created under your email, with you as the owner, and the developer is invited as a collaborator. If they leave, you remove their access and nothing stops working. If the accounts live under the developer's name, you are one disagreement away from losing access to your own business tool.

## How we handle it at SteelPine

We set projects up so you own everything from the first day, not at the end. Your code lives in your repository, and your hosting, domain, store and service accounts are created on your own email. We work inside them as collaborators. When a project finishes there is nothing to transfer, because nothing was ours to begin with.

We also write documentation as we go, so another developer could pick up the work without calling us. If you want ongoing support afterwards, it is optional. A retainer is only worth paying for if your software actually needs ongoing work, and for an app with a handful of users it usually does not.

## A quick handover checklist

Before the final payment on any project, confirm you can do each of these yourself:

1. Log into the repository and see the full history.
2. Log into hosting and see where the app runs and what it costs.
3. Rebuild and deploy the app from the documentation.
4. Find every secret key and service login, stored somewhere you control.
5. Restore the database from a backup.

If you cannot do all five, the project is not really handed over yet.

## Questions to ask any developer

- Who will own the code, and where is that written down?
- Whose email will the hosting, domain and repository accounts be under?
- What third-party or open-source code are you using, and under what licenses?
- If we stop working together next month, what exactly do I lose access to?
- Will you document how to deploy and run it?

The answers are usually clear within a minute. Vague answers are a good reason to keep looking.

You can see how we work in the [pricing and process](/#pricing) section of the home page, or book a free call to talk through your own project.