Who owns the code when you hire a software company?

Most software contracts are vague about who owns the finished code. That vagueness is not neutral. Under US copyright law, the person who writes the code usually keeps it unless a signed document says otherwise. So if you paid for a system and the agreement is silent, you may have bought a licence to use something you don't own. Here is how ownership actually works, what to ask for, and where owning the code helps you less than you'd hope.

People assume that paying for something means owning it. Buy a laptop, own the laptop. Software doesn't work that way. Copyright attaches to the author the moment the code is written. If the author is your employee doing their job, your company owns it automatically. If the author is an outside firm or a freelancer, the author owns it, and you get whatever rights the contract gives you. Pay in full, get the files, use the system happily for three years, and the developer can still hold the copyright.

There's a phrase that shows up in nearly every development contract. Work made for hire. Owners read it and relax. In US copyright law that term has a specific, narrow meaning. For work by a non-employee, it only applies to nine listed categories, including films, translations and contributions to collective works. Custom business software is not on the list. A court can decide the clause does nothing at all.

That's why good contracts don't rely on it. They add a present-tense assignment. Something like "Developer hereby irrevocably assigns to Client all right, title and interest in the deliverables." The word "hereby" matters. It transfers the rights now, rather than promising to transfer them later, which keeps you out of trouble if the firm shuts down or sells. Then there's usually a third layer, a broad perpetual licence that applies if the assignment is ever held invalid. Belt, braces, and a spare belt.

There are two ways a firm can give you rights. Assignment means the copyright moves to you. You become the owner. You can change the code, sell it, give it away, or hire anyone you like to work on it. A licence means the firm stays the owner and grants you permission to use the work under stated terms.

Licences are not automatically bad. They're how most of the software industry functions. The problem is what sits inside the terms. A licence can be limited to a number of users. It can be limited to one location or one entity, which becomes a mess if you acquire a company or spin out a division. It can forbid you from modifying the code. It can forbid you from letting another developer touch it, which ties the firm to every future change. And it can terminate. Read the termination section of any licence carefully, because a licence that ends when the support contract ends is a rental with extra steps.

If you're commissioning a system that runs a core part of your business, press for assignment. Order intake, scheduling, quoting, production tracking, client portals. These are the systems you cannot switch off. Renting the rights to your own operations is a bad position, and the cost difference at the point of signing is usually small or zero.

Where a licence is reasonable is when the firm has a genuine pre-existing product or framework and your project is a layer on top of it. Nobody is going to hand you ownership of the platform they've spent six years building and resold to forty other clients. That's fair. What you want in that case is ownership of everything specific to you, plus a perpetual, irrevocable, transferable licence to the underlying pieces, with the right to modify them and to hire any developer you choose.

Nearly every assignment clause has an exception for the developer's pre-existing material. It's often called background IP or developer tools. Good firms have internal libraries. Reusable authentication, reporting components, deployment scripts. They've been refining them for years, and they're not giving them away because you hired them for one project.

The carve-out itself is normal. What matters is how wide it is. A tight version lists the components by name and grants you a perpetual licence to use and modify them as part of your system. A loose version says "anything Developer created before or during the engagement that is of general applicability", which can swallow the whole project. Under that wording, the firm can argue that the scheduling engine, the one piece you actually paid for, is a general-purpose component they happen to be licensing to you.

Ask for the list. If a firm can't tell you which parts of your system are theirs and which are yours before they start, they won't be able to tell you afterwards either.

Owning the source code and nothing else is like owning a car engine without the car. You need the whole package to be free to move. Here's what a real handover includes.

• The repository itself, with full history. The code store should live in an organisation account your company owns, with you as owner and the developers added as members. Not the other way round.
• Build and deployment instructions that someone else can follow. A new developer should be able to get the system running on their own machine from a written document, without a phone call.
• Environment configuration, meaning the list of settings and secret keys the system needs to run, stored somewhere you control.
• Database schema and migration scripts, which are the files that create and update the structure of your data.
• Design files, so you're not re-drawing screens from scratch when you change something.
• Any automated tests, which are the checks that tell a future developer whether a change broke something.
• Architecture notes explaining why things were built the way they were. This is the thing nobody writes and everyone needs.

I'd push the repository point hardest. It sounds administrative. It isn't. If the code lives in the vendor's organisation, every single thing about your software runs through their permission. A billing dispute, a staff departure or a quiet acquisition and you're locked out of the thing you paid for. Set it up correctly on day one and it costs nothing. Fix it later and it's an awkward conversation during an already awkward moment.

Code ownership and infrastructure ownership are two different things, and the second one is where most businesses get stuck. Your system runs somewhere. A cloud account, a database host, an email sending service, a payment processor, maybe a mapping or document signing API. Each of those is an account with an owner, a billing method and a password.

If your developer opened all of them under their own account and bills you back, you don't control your own system. You can own every line of the code and still be unable to deploy a fix, because the deployment pipeline is in someone else's account. I've seen plenty of handovers where the code transfer took an hour and the account transfer took weeks of emails to five different support desks.

Do it the simple way. Your company creates the cloud account with your own payment method. Your company owns the domain registration. You invite the developers in with the access they need. When the engagement ends, you remove their access and nothing else changes. The domain is the one people most often lose track of, and it's the one that takes your email down when it lapses.

No modern software is written entirely from scratch. Your system is built on open source libraries, and the people who wrote those libraries own them. You get a licence. For the common ones, MIT and Apache 2.0, the licence is permissive and the obligations are tiny. You keep the copyright notices and you're done.

Copyleft licences are the ones to watch. GPL and especially AGPL require that if you distribute the software, or in AGPL's case even just run it as a web service that others use, you make your source code available under the same terms. If your system is purely internal, that's usually irrelevant. If you ever want to sell the system as a product, or offer it to clients as a hosted service, one AGPL component in the wrong place can force you to publish your own source code. This is a solvable problem when you catch it during the build and an expensive one when you catch it during due diligence.

The same applies to commercial components. A charting library, a PDF engine, a grid control. These are licensed per developer or per deployment and they stay owned by the vendor. Ask for a written list of every third-party component, its licence type, and whether it carries a recurring fee. A firm that does this properly already has the list generated automatically.

Then there are the services your system calls. Payment processing, email delivery, text messages, mapping, accounting APIs. You will never own those and you shouldn't want to. What you want is for those accounts to be in your name, so the relationship is yours and not your vendor's.

Code ownership clauses often say nothing about data, which is strange, because your data outlives the software. Customer records, job history, invoices, documents, photographs, signatures. Put a clause in that says your business data is yours, that the developer holds it only to provide the service, and that on request you get a complete export in a documented, usable format. Usable is the operative word. A proprietary backup file you can't open isn't an export.

This matters more when the system is hosted by the vendor. If it's in your own cloud account, you already hold the data. If it's in theirs, write down the export right, the format, the timeframe, and what happens to their copies afterwards. Also check whether any client contracts or regulations apply to that data, because healthcare, financial and government work all add requirements that need to be designed in rather than bolted on.

One more thing. Attachments and files are the hardest part of any migration. A twelve-year history of job photos and signed PDFs stored across a vendor's file service doesn't move with a copy and paste. It takes a scripted export that walks every record, pulls the files, and rebuilds the links on the other side. Agreeing in advance that this is included in handover saves a genuinely miserable month later.

This is the part that gets skipped in most articles on the subject, and it's the part that saves you money.

You still need someone who can run it

Owning the code doesn't make you capable of changing it. If the system is undocumented and built in an unusual way, the next developer's first three weeks go to reading. Ownership protects you from being held hostage. It doesn't remove the cost of maintenance, hosting, security updates and the occasional broken integration when a third party changes their API. Budget for ongoing care or the asset decays.

Ownership doesn't mean exclusivity of ideas

Your contract gives you the code. It doesn't stop the firm from building something similar for someone else, using the same patterns and the same general approach. You can negotiate a non-compete on similar work, but good firms charge for that, and honestly most businesses don't need it. Your advantage is in how your operation runs, not in the fact that you have a scheduling screen.

Owning a bad codebase is worse than renting a good product

If the build is poor, ownership just means you own the problem. Ownership is only worth fighting for when the thing being built is worth having. Judge the work, the documentation and the handover discipline first. The clause second.

Sometimes you shouldn't be building at all

If your need is standard, buy standard. Accounting, payroll, email and general CRM are mature, cheap and heavily regulated categories where a custom build is a bad trade. Custom earns its keep where your process is genuinely yours, where off-the-shelf forces you into workarounds, where per-seat pricing punishes you for growing, or where you're paying for five tools and a human to copy data between them. If a $60 a month product does the job, use it and spend your money elsewhere.

Here's how to compare honestly. Take the SaaS you'd otherwise renew and work out the five year total, not the monthly figure. Say you have 60 people on a field service platform at $90 per user per month. That's $64,800 a year. Add a $400 a month integration connector to push jobs into your accounting system and you're at $69,600. Most vendors raise prices each year, so apply a modest 7 percent annual uplift. Over five years that's roughly $400,000, and you own nothing at the end of it. Hire ten more people and the number climbs again.

Now put the build on the other side. One-off cost to design and build it, plus hosting, plus a realistic annual maintenance budget. Hosting for a system serving 60 internal users is normally modest, often a few hundred dollars a month on a mainstream cloud provider. Maintenance is the line people underestimate, so be generous with it. Then compare the two five year totals, and remember that in the build column the per-seat cost of your 61st employee is zero.

The arithmetic doesn't always favour building. With 8 users instead of 60 the SaaS total is small and the build rarely pays back. With a very standard process and no integration pain, the SaaS wins again. But at scale, with per-seat pricing and a process that doesn't fit the tool, the gap gets wide enough that it stops being a close call. Run the numbers with your actual headcount and your actual renewal quote before you decide either way.

You don't need to be technical to run this conversation. Ask these, plainly, and listen to how quickly the answers come.

1. Does the contract assign copyright to us, using the word "hereby", and not just the phrase "work made for hire"?
2. Do your employees and subcontractors have agreements assigning their work to you, so you can pass it to us?
3. Which pre-existing components of yours will be inside our system, and what licence do we get for them?
4. Will the repository live in our organisation account from the first day of the project?
5. Will the cloud, domain and third-party service accounts be opened in our name with our payment method?
6. Can you produce a list of every open source and commercial component, with licence type?
7. What exactly do we receive at handover, and will you walk a new developer through it if we ask?
8. If we stop working with you tomorrow, what breaks, and what do we need from you to keep running?

The last question is the honest one. Watch for the firm that gets uncomfortable, because the discomfort tells you where the lock-in is.

At Black Badger we assign the code to the client and we set the accounts up in the client's name from the start. That's the whole philosophy of the firm. We used to be a platform partner and we left, because selling other people's licences and building systems people own outright are two different businesses. You keep the repository, the documentation and the keys. If you decide to work with someone else in three years, you can, and nothing about that is a problem for you.

If you're holding a draft contract right now, do three things today. Read the intellectual property section and find out whether it contains the word "assigns". Check who the domain is registered to. Ask your developer where the repository lives. Those three answers will tell you most of what you need to know about how much of your own software you currently control.

If you'd like a second pair of eyes on your current setup, or you're weighing a renewal against a build, you can book a free strategy session with us. We're in Clearwater and we work across Pinellas and Hillsborough counties.

If this prompted you to check your own setup, read our piece on what a proper software handover package should contain. It turns the checklist above into something you can actually request in writing.

• What belongs in a software handover package, and how to verify you got it
• Per-seat pricing and the point where renewal stops making sense
• Buy, build or extend, a plain-English way to decide
• How to replace five disconnected tools without breaking the business