Who Owns the Code, Logins, and Data? Settle This Before You Sign

A vendor says, “Don’t worry, you’ll own everything.” Don’t sign until “everything” is spelled out in plain English: who owns the custom code, who controls the accounts, and how you get your data out if the relationship ends.

This is one of those decisions that feels legal, but it turns into an operations problem fast. On paper, you may “own the software.” In real life, if the domain is in their name, the cloud account uses their email, and the only admin login goes to their phone for MFA, you do not control your business.

Ownership is not one thing

Business owners get burned here because they treat ownership like a single checkbox. It isn’t.

Think of it like building a restaurant. The building, the lease, the kitchen equipment, the recipes, the utility accounts, and the front-door keys are all different things. Software is the same way.

You need the contract to separate:

• Custom code created specifically for your business
• Pre-existing vendor tools like templates, internal libraries, frameworks, and reusable components
• Third-party software you’re paying for or relying on
• Logins and admin access for hosting, domain, email, app stores, analytics, and code repositories
• Business data including customer records, files, submissions, and operational history
• Exit rights for transfer, export, shutdown, and transition help

A vague line that says “client owns the work product” is not enough. I’d rather see a boring, specific contract than a friendly, fuzzy one.

My call: control matters more than bragging rights

Here’s my opinion: if you can’t take over the system without begging the vendor, you don’t really own it.

That’s why I care at least as much about account control as I do about source-code ownership.

I’ve seen business owners focus hard on whether the code is assigned to them, while ignoring the stuff that actually keeps the lights on:

• DNS registrar access
• Cloud hosting root account
• GitHub or GitLab organization ownership
• Deployment pipeline access
• Database credentials
• Apple or Google developer accounts
• Backup access
• MFA devices and recovery methods

That’s the digital version of owning the building deed while your contractor keeps the only keys, the alarm code, and the utility account passwords.

If you’re hiring a developer for a custom software project, this needs to be settled before the first invoice, not during a breakup.

What you should ask for in the contract

You do not need a giant enterprise contract. You do need clear terms.

Here’s the practical breakdown I’d want in front of me.

• Custom-built code: assign ownership to you after payment, or at minimum give you a perpetual, transferable, irrevocable license to use, modify, and hire someone else to maintain it.
• Vendor’s pre-existing tools: vendor keeps ownership, but you get a broad license to use them as part of your system.
• Third-party components: list the major outside services, packages, and license obligations. Open-source code does not magically become exclusive just because it’s inside your app.
• Accounts: your business should own the primary accounts whenever possible, using an email address you control.
• Admin access: you should have admin-level access or a documented break-glass process.
• Data: contract should define what data is yours, what the vendor may do with it, and how it is returned or deleted.
• Export rights: require a usable export format, not some useless dump nobody can read.
• Exit help: define handoff steps, timing, documentation, repository transfer, and paid transition support if needed.
• Backups and logs: say what happens after termination. Are they deleted, retained for a period, or available for transfer?
• Recovery channels: spell out whose phone, email, authenticator app, and recovery codes are tied to critical systems.

If you want a good companion read, this is the same reason I tell owners to map the handoff process before hiring.

Don’t confuse code ownership with data rights

This part gets messy fast.

A lot of owners say, “I want to own my data.” Fair. But with business systems, the better question is: who is allowed to use, export, retain, delete, or share the data?

That matters because customer data, employee data, and uploaded files are not like a pickup truck you put a title on. If personal data is involved, privacy rules can shape what the vendor can do, what you can demand back, and how deletion has to work.

So don’t stop at “client owns data.” Make the agreement answer:

• What counts as your data?
• Can the vendor use it for analytics or product training?
• How quickly can you export it?
• In what format?
• What happens to backups?
• What gets deleted, and when?
• Will they help migrate it to a new system?

If your business relies on multiple systems talking to each other, this connects directly to software integration decisions and to what happens when one vendor disappears.

The contractor rule matters more than people realize

Under U.S. copyright law, work created by employees is usually owned by the employer as work made for hire. Independent contractors are different. If you hire a freelancer, agency, or outside developer, ownership usually comes down to the written contract.

That means if the agreement is sloppy, you may pay for software and still not receive the rights you assumed you were buying.

This is one reason I prefer direct, plain-language expectations with business owners across Northwest Arkansas and the Ozarks. Fewer surprises later.

What not to do

A few mistakes I’d avoid completely:

• Don’t let critical accounts live under a vendor’s personal email.
• Don’t accept shared passwords in a spreadsheet as your “handoff plan.”
• Don’t assume paid-for means owned.
• Don’t demand ownership of every tool if a strong license solves the problem better. Sometimes the vendor has reusable building blocks they use across projects. That’s normal.
• Don’t ignore open-source and third-party licenses. You may own the custom work without owning every ingredient inside it.
• Don’t wait until the relationship sours to ask about exports, backups, and admin access.

If you’re comparing proposals right now, also read how to read a software proposal without missing the expensive parts.

Common questions

Who should own the domain, hosting, and cloud accounts?

Your business should own the primary accounts whenever possible. A developer can be added as an admin, but the root control, billing access, and recovery methods should point back to your company.

If I pay for custom software, do I automatically own the code?

No. If an outside contractor builds it, ownership usually depends on the contract language. Payment alone does not automatically transfer copyright.

What if the developer uses their own framework or reusable components?

That’s common and not automatically a problem. The key is making sure you either own the custom parts or have a broad, permanent right to use and maintain the full system.

What’s more important: owning the code or being able to take over the system?

If I had to pick one practical priority, I’d pick takeover ability. Paper ownership without login control, export rights, and documentation is like owning a car with no keys.

Settle ownership, access, and exit rights before you sign, because the worst time to learn who controls your software is when you need it back.

If you're staring at this exact problem, that’s the kind of thing I help businesses sort out before and during a build — here’s how Custom Software Development works.