Picture a business owner we'll call Dana. Four years ago she paid a freelancer to build a scheduling app. It worked. Then he took a full-time job elsewhere and stopped answering email.
Last month the app broke. A new developer asked, "Where's the code?" Dana didn't know. The hosting account and the domain were in the freelancer's name, and the only copy of the source code lived on his laptop.
Dana had paid for the software. She did not own it in any way she could use. This is the heart of the question who owns custom software, and it's worth asking before the first line of code is written, not after the app breaks.
One thing up front: this is general business information, not legal advice. Ownership rules vary by state and country, and your contract is what actually decides. We'll point out what to look for, and we'll say plainly when it's time to hand it to an attorney.
Who owns custom software by default?
Most people assume that paying for something makes it theirs. With a physical product that's true. With software it's more complicated.
In many places, the person who creates a piece of work holds the copyright unless an agreement says otherwise. A freelancer or an outside company usually isn't your employee, so if the contract is silent, the builder may own the code and you may only have permission to use it.
That's why "I paid for it" isn't a plan. Who owns custom software comes down to what's written down, and it comes in layers:
- The code the developers wrote.
- The data your business puts into the system.
- The accounts where the software lives: hosting, domain, code repository.
- The knowledge of how it all works, in the form of documentation.
You can own some layers and not others, and that's where people get hurt. Let's take them one at a time.
The code and the IP assignment clause
The code is the part everyone thinks of first, and the part a contract has to address in so many words.
The phrase to look for is an intellectual property assignment. It's a clause where the builder transfers their rights in the finished work to you. A good one says the transfer happens when you've paid, and it covers the software built specifically for you.
Compare that with a license, which only gives you permission to use the software, often with conditions. A license can be fine for a subscription product. For something you commissioned and paid to have built, most owners expect assignment, and they should ask for it.
Your code versus their toolbox
No builder starts from zero. They use open source libraries and their own reusable pieces, like a login system or a form component. It's normal for a builder to keep their general-purpose tools while handing you what was made for you. What you want the contract to make clear is the split:
- What was created specifically for your business belongs to you.
- Generic tools the builder brought along stay theirs, but you get the right to keep using them inside your software.
- Open source components keep their own licenses, which should be listed.
If a builder wants to keep everything and lease it back to you, that changes what you're buying. Ask directly and get the answer in writing.
A few clauses worth reading twice
When you read a software agreement, slow down on these:
- Assignment or license? Does the contract transfer ownership, and when?
- Payment conditions. Some agreements transfer ownership only after final payment. That's fair, but make sure you know the trigger.
- Reuse. Can the builder reuse code written for you? For generic parts, probably yes. For your confidential logic, it should say no.
- Third-party components. Are licenses for any bundled tools listed, and who pays for them?
- Exclusivity language. Make sure nothing quietly stops you from hiring someone else to maintain the software.
If this reads like a foreign language, that's the clearest sign an attorney should look at the draft.
Hosting, domain and accounts in your name
Of all the layers, this is the one we see go wrong most often, and the easiest one to prevent.
The rule is simple: your business should own every account, and your builder should be a user on them. Not the other way around.
Software needs hosting, a domain, a code repository and often a few other services. Each is an account, and the account owner holds the keys. If the builder owns the web hosting account and you part ways badly, you can't move, can't shut things off and can't retrieve your own files without their cooperation. The same goes for your domain name. Lose control of the domain and you can lose your website and email in the same afternoon.
A short checklist you can use on day one:
- The domain is registered under your business name and your email.
- The hosting and any cloud services are billed to your company.
- The code lives in a repository your business owns, with your builder invited in.
- Passwords and recovery codes sit in a password manager you control, with two-factor authentication turned on.
- At least two people on your side know where all of this is.
If your software is a few years old, spend an hour this week checking each item.
The data inside the system
The software is the tool. The data is the asset: customer records, job history, invoices, files. It's yours in principle, but that only counts if you can get it out. Ask your builder three things:
- Can I export everything, in a format I can use? A spreadsheet-friendly export or a standard database backup both count. "We can pull a report for you" doesn't.
- Where is it stored, and who else can see it? You should know which hosting service holds it and who has access.
- Is it backed up, and could I restore it elsewhere? A backup you can't restore is a comforting rumor.
If the system holds customer information, you may also have privacy obligations. That's another one for your attorney.
Documentation and the "what if my developer disappears" test
Here's a test we like. Imagine your builder is unreachable tomorrow, for any reason: a new job, an illness, a closed business. Could another competent developer take over within a few weeks?
If yes, you own your software in a practical sense. If no, you own a very nice dependency.
What makes the answer yes:
- The code is in a repository you control, with its history, not a zip file on someone's desktop.
- There's a plain-language document explaining what the system does, how it's put together, how to run it and how to deploy changes.
- Setup is repeatable. A new developer can get a working copy running without a mystery phone call.
- Credentials and settings are recorded, safely, somewhere you can reach.
- There's a team, not a person. Software built by a small studio with shared knowledge is less fragile than software that lives in one person's head. This is one reason continuity belongs on your list when you hire a web development company.
Builders skip documentation when deadlines get tight, so ask for it in the scope of work.
A good builder is easy to leave. That's the point.
How we answer "who owns custom software" at Stack Mode
When we build custom software for a client, the code, the data and the accounts are set up to belong to the client's business. We join as users instead of holding the keys. We keep the code in a repository the client can access and we document how it works. If a client ever wants to take the software elsewhere, we'd rather that be easy than have them feel trapped.
We run our own business on StackOS, so we know how it feels to depend on software. We'll walk through ownership in plain English in the first conversation, and we'll tell you to have your own attorney read the agreement. That's not a formality.
Questions to ask before you sign
Whether you work with us or someone else, take these into the room. They pair well with our guide to questions to ask a web designer, which covers the website side of the same conversation.
- Who owns the code when the project is finished, and when does that transfer happen?
- Which accounts will be in my name?
- Can I get a full export of my data at any time?
- What documentation will I receive, and what's the plan if you're unavailable?
If you're still weighing whether to build at all, our walkthrough of build vs buy software covers that decision, and ownership is one of the biggest differences between the two. The U.S. Small Business Administration also publishes general guidance on setting up and protecting a business, a decent starting point before you talk to an attorney.
The takeaway on who owns custom software is short. Don't ask only "will it work?" Ask "will it be mine?" Get the answer in writing, put the accounts in your name from day one, and have an attorney read the contract. That's how you avoid becoming Dana.