Who Owns Your Code? Checking a Software Development Contract

You paid for the customer portal, the dispatch app or the inventory sync. It runs your business every day. But if your developer stopped answering the phone tomorrow, could you log in, find the code and hand it to someone else?

Many owners find out the answer only when something goes wrong. A software development contract is where you settle it ahead of time, and most of the important questions fit on one page.

This article is a practical checklist, not legal advice. Have a lawyer review any contract before you sign it.

Ownership of the code itself

Start with intellectual property. In the US, code written by an outside contractor generally belongs to the contractor unless a written agreement says otherwise. Paying the invoice does not, by itself, make you the owner.

Look for a clause that assigns the custom work to you, usually once it's paid for. Words like "license" or "right to use" are not the same as ownership. A license can be limited, revocable or tied to an ongoing fee.

Expect one reasonable exception. Most developers reuse their own building blocks, such as a login module or a reporting framework they built years ago. The contract should name that pre-existing material and give you a permanent, transferable license to use it as part of your system. Without that license, you might own the custom parts but be unable to run them.

Questions to ask:

• Does the contract assign ownership of custom work to my company?
• What pre-existing code does the developer keep, and what license do I get to it?
• If subcontractors write any of the code, are they bound by the same terms?

Where the code and accounts live

Ownership on paper means little if you can't reach the thing you own. The cleanest setup is that everything sits in accounts registered to your company, with the developer invited in as a user.

That includes:

• The code repository, such as GitHub, GitLab or Bitbucket, under an organization your company controls
• Hosting and cloud accounts, like AWS, Google Cloud, Azure, Vercel or Netlify
• Your domain name and DNS, registered in your company's name with a company email address
• App store accounts for Apple and Google Play, so your mobile app is published under your business, not the developer's
• Third-party services the system depends on, such as Stripe, Shopify, HubSpot, QuickBooks or an email provider

Make sure at least one person at your company holds admin access to each account, not just a viewer seat. Keep the list of accounts somewhere you control, and update it when people join or leave.

If your business can't function without a system, someone on your payroll should hold the keys to it.

Moving an app or domain between owners later is usually possible, but it can be slow and depends on the other party cooperating. It's far easier to set things up correctly on day one. This is especially true for mobile apps, where the store listing, reviews and update history are tied to the publishing account.

Your data, and how to get it out

Your customer records, orders and job histories are often worth more than the code. The contract should say plainly that the data belongs to you.

Then check the practical side. Can you export everything in a standard format, such as CSV, JSON or a full database backup, at any time and without asking permission? Where are backups stored, how often are they taken, and who can restore them?

If the system holds customer or employee information, the contract should also cover how it's secured and what the developer must do if there's a breach.

Third-party licenses and open source

Almost every modern system uses open-source libraries and paid services. That's normal and usually a good thing. The risk is in not knowing what's in there.

Ask for a list of the major third-party components and the licenses they use. Some open-source licenses carry conditions about sharing your own code if you distribute the software, so it's worth knowing which ones are involved.

For paid services, like a mapping API, an SMS provider or a premium plugin, find out whose name the subscription is in. If it's on the developer's card and they leave, the feature can stop working without warning. It's usually better for those accounts to be in your company's name.

Documentation and handover

Code without documentation is hard for anyone else to pick up. A good contract asks for a handover package that another competent developer could use to get started.

At a minimum, that means:

1. A plain description of what the system does and how its parts connect
2. Setup instructions for running it and deploying updates
3. A list of every account, service and integration, with who owns each one
4. Where credentials are stored, using a password manager or secrets vault, not a spreadsheet emailed around
5. Notes on any known limitations, workarounds or scheduled jobs

Ask that documentation be kept up to date as the work goes, not written in a rush at the end. A planning phase that produces written designs and a clickable prototype, like the Blueprint stage in our approach, gives you a head start on this.

What happens if you part ways

Every working relationship ends eventually, sometimes on good terms and sometimes not. The contract should describe how that goes before anyone is upset.

Check for:

• Notice period. How much notice either side must give.
• Transition help. Whether the developer will help hand over to a new team, and on what terms.
• Delivery of everything. Final code, documentation, credentials and data, delivered within a set number of days.
• Removal of access. Confirmation that the developer's access is removed and any copies of your data are deleted or returned.
• Payment disputes. What happens to ownership if there's a disagreement over an invoice. Some contracts hold back ownership until everything is paid, which is fair, but you want the process spelled out.

If the developer insists on hosting the software themselves, ask about source code escrow, where a neutral third party holds a copy of the code that's released to you under defined conditions, such as the developer going out of business.

Red flags worth a second look

None of these automatically rules out a vendor, but each deserves a direct question:

• The developer owns the code and you get a license
• The repository, hosting or domain is in the developer's name
• No mention of data export
• "Proprietary platform" with no explanation of what happens if you leave
• Vague promises of documentation with nothing written into the contract

Good partners usually answer these questions quickly, because they've already thought about them. That's how we work on custom software projects: clients own their accounts, code and data from the start.

Where to start

You don't need to wait for a new project to check this. Here's what you can do this week:

1. List every system your business depends on, from your website to your scheduling tool.
2. For each one, write down who owns the code, the hosting account and the domain.
3. Log in to each account yourself and confirm you have admin access.
4. Run a test data export from your most important system and open the file.
5. Pull out your current development contracts and highlight the ownership, data and termination clauses for your lawyer to review.

If that exercise turns up gaps and you'd like help sorting them out or planning a handover, you can reach us here.

General information only, not legal, tax or financial advice. Examples and figures are illustrative.