Who Owns the Code, Data, and Accounts?

A Gulfport engineering firm paid a local developer $200,000 over three years to build custom project management software. When the developer decided to retire, they offered to sell the source code to the firm for $80,000.

The firm said they'd already paid for it. The developer said they'd licensed it, not purchased it. The contract—written by the developer—said "client receives a license to use the software."

The firm paid again.

This happens. It shouldn't.

The ownership basics

Technology ownership breaks down into a few categories. Understanding each one matters.

Code ownership

When someone writes software for you, who owns it?

Three scenarios:

1. Work for hire (you own it): The code is created specifically for you. You own it completely. You can modify it, sell it, or stop using it. This is what you want.

2. Licensed (they own it): You can use it, but you don't own it. The developer can license it to others. You may not be able to modify it. This is what happened to the Gulfport firm.

3. Open source (complex): Code that exists under various licenses. Some allow commercial use. Some don't. Some require you to share modifications. Some don't. This is its own rabbit hole.

The question to ask: "Do we own the source code?" The answer should be yes, or you should understand exactly what "license" means.

Data ownership

Data is what your systems store. Customer records, transactions, files, databases.

Who owns your data?

You do. Almost always. This is rarely disputed—but sometimes the practical ability to get your data out is.

The questions to ask:

• Can we export all our data?
• In what format?
• Is there a fee?
• What happens if we cancel?

These questions reveal more than the ownership statement. A vendor who says "you own your data" but makes export difficult is telling you something.

Account ownership

Domain names. Cloud services. Software subscriptions. Licenses.

Who owns your accounts?

You should. But often vendors set these up in their names for convenience—and then "convenience" becomes dependency.

Specific things to check:

• Domain names: Are they registered to you or your vendor? Is the registrar account in your name?
• Cloud services (AWS, Azure, Google Cloud): Are the accounts under your company email or theirs?
• Software licenses: Are they assigned to you or "licensed to [Vendor Name] on behalf of [Your Company]"?
• SSL certificates: Who generated them and where are they stored?

Why this matters

Ownership matters when:

You want to leave. If you don't own your accounts, you can't leave cleanly. You depend on the vendor's goodwill.

The vendor closes. If your vendor goes out of business, what happens to your accounts? Are they transferred to you, or do they disappear?

You want to modify things. If you own the code, you can hire anyone to maintain it. If you license it, you're dependent on the original developer.

You want to sell the business. Business buyers want assets they can take with them. Software you don't own is worth less—or nothing.

Real scenarios

The domain name trap

A Pensacola business hired a web developer who registered their domain name. The developer used their own registrar account. Three years later, the relationship soured. The developer refused to transfer the domain.

The business had to register a new domain, rebuild their web presence, and update all their marketing materials. Six months of damage.

How to avoid it: Register domains in your company name. Use your own registrar account. Give vendors access if needed, but keep ownership.

The cloud account trap

A Mobile company had their entire infrastructure on AWS. The account was set up by their MSP. The MSP owned the account.

When the MSP raised prices dramatically, the Mobile company wanted to leave. But the AWS account was in the MSP's name. They couldn't easily move because all the infrastructure was tied to an account they didn't control.

They paid the higher prices for another year while they migrated.

How to avoid it: Cloud accounts should be in your company name. Your vendor can be an admin user, but you should be the account owner.

The custom software trap

A Destin company paid $150,000 for custom software. The contract said the software was "licensed to client." They thought that meant they owned it.

They wanted to add features. They hired a different developer. The new developer couldn't work on it because they didn't have the source code—only the original developer did.

They had to go back to the original developer, who charged $15,000 to make changes that should have been trivial.

How to avoid it: Get explicit ownership in the contract. "Work for hire" or "client owns all intellectual property including source code" is what you need.

What good looks like

A Gulf Coast manufacturing company learned from others' mistakes. Before signing any contract, they required:

• All domains registered in their company name
• All cloud accounts under their company email
• Source code escrow for any custom software (a third party holds the code; they can retrieve it if the developer disappears)
• Explicit IP ownership language in all contracts
• Data export capability verified before signing

They paid more attention upfront. When they wanted to switch vendors, it took three weeks and cost almost nothing.

What to check now

Even if you signed years ago, check:

1. Domain registrar: Log in and confirm domains are in your company name.
2. Cloud accounts: Check who owns your AWS, Azure, or Google Cloud accounts.
3. Custom software contracts: Read the ownership clause. Do you own the code?
4. SSL certificates: Do you have access to renew them if needed?

If you find problems, document them. Work with your vendor to fix them if possible. If they won't cooperate, that's information.

Questions to copy/paste

Ask before signing any contract:

• "Who will own the intellectual property for any custom code written?"
• "Will we receive the source code? Under what conditions?"
• "Will we be named as the registrant for all domains?"
• "Will cloud accounts be in our company name?"
• "How do we export all our data if we cancel?"
• "What happens to our accounts and data if you close?"

What it costs to get this wrong

Domain names: $500-$5,000 to rebuild online presence if you lose control

Cloud accounts: $10,000-$50,000+ to migrate infrastructure you don't control

Custom software: $50,000-$200,000+ to rebuild software you thought you owned

Data loss: Incalculable if you lose customer records, financial data, or operational data

When to hire help

Hire someone to audit your ownership situation when:

• You have custom software and haven't reviewed the contract
• You've had a bad relationship with a vendor and might want to leave
• You're planning a sale or transition of the business
• You don't know the answers to the questions above

A ownership audit takes 4-8 hours and costs $500-$2,000. It's worth it.

The bottom line

Ownership isn't complicated, but it's often ignored. Most SMBs don't think about it until they need to leave a vendor.

By then, it's too late.

Check your accounts. Read your contracts. Know what you own.

The time you spend now is far less than the time you'll spend fixing it later.