Here is a situation common enough that most people who have commissioned software will recognize some part of it. A company pays for a system, uses it daily for two years, and could not move it anywhere if it had to. The application runs in a hosting account the developer opened. The domain sits in the developer's registrar. The database is reachable with a password nobody inside the company has. The invoice said "custom software development," and everyone assumed that settled the question of ownership.

It does not settle it. It rarely does.

This is not usually a story about bad actors. Most builders are not planning to hold anything hostage. The accounts end up in their name because it was faster at the start, and the paperwork never catches up because the software works and nobody has a reason to look. Then something changes. The builder gets busy, or moves on, or the relationship sours, or someone leaves the company and takes the only working knowledge of the system with them. That is when ownership stops being a legal abstraction and becomes an operational problem.

Here is what you should actually own, why the default is not what most operators assume, and what to ask for before you sign.

The legal default is not what most people expect

Start with the part that surprises operators most. In the United States, paying someone to write software does not, by itself, make you the owner of the copyright in it.

The copyright statute says that copyright "vests initially in the author or authors of the work" (17 U.S.C. 201(a)). There is an exception for a work made for hire, where "the employer or other person for whom the work was prepared is considered the author." That exception is narrower than the phrase sounds. Under the definition in 17 U.S.C. 101, a work made for hire is either a work prepared by an employee within the scope of employment, or a specially commissioned work that falls into one of nine listed categories and is covered by a written instrument signed by both parties.

Read the nine categories: a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas. Software is not on the list. A commissioned application is generally not a work made for hire no matter what the contract calls it.

The mechanism that does move ownership is assignment, and it also has a formality: a transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed" (17 U.S.C. 204(a)). A signed writing, from the person who made the thing, to you.

We build software, not law, and none of this is legal advice for your situation. The practical takeaway is small and worth acting on: your agreement should contain an explicit assignment of intellectual property, not a vague reference to work for hire, and it should be signed. If your existing contract does not have one, that is a fixable problem today and an expensive one later, when the code you thought you owned is a bargaining chip in a dispute.

The code is the smallest thing you need

Even with a clean assignment, the copyright is not the asset that keeps a business running. Suppose we handed you a zip file of every line of source code this afternoon. Could you run the system tomorrow? For most operators the honest answer is no, because the code is one item on a list of five, and the other four are the ones that hurt when they are missing.

The accounts

Every running system sits on a stack of accounts: a hosting or cloud provider, a domain registrar, DNS, a database or backend service, an email sending service, error tracking, analytics, maybe a payment processor. The question for each one is simple and rarely asked during a build. Whose name is on it, and whose credit card is attached?

The right shape is that the accounts belong to your business, billed to your business, with the builder invited in as a collaborator or administrator. This costs nothing extra at the start of a project. Retrofitting it later is a chore at best. Domains and payment processors are the sharpest cases, because moving a domain requires cooperation from whoever holds it, and a payment processor account is tied to a legal entity and cannot simply be handed across.

There is one exception worth naming, because it is legitimate. Some builders run your system on their own infrastructure deliberately, as a hosted arrangement, and price it that way. That is a real product, not a trap. What makes it fair is that it is disclosed, and that there is a written answer to the question of what happens to your data and your service if you leave.

The credentials

Related but distinct: the keys. API keys, service accounts, OAuth credentials, deploy tokens, the login to the admin panel. These tend to live in the builder's password manager, and often in only that one place.

You do not need to hold every key in your hand day to day. What you need is a written inventory of which credentials exist, which account each one belongs to, and how to rotate them. A system whose secrets are known to exactly one person outside your company is a system with a single point of failure that has nothing to do with technology.

The data

Your data is yours in every sense that matters, and it is still possible to be practically unable to get at it. Ask two questions. Can you export everything, in a usable format, without the builder's help? And are there backups you can actually restore from, rather than backups that are asserted to exist?

A useful sanity check for any live system: ask for an export today, while everyone is friendly. If it arrives in an hour, your data is portable. If it takes a week of custom work, your data is technically yours and functionally captive, and now you know before it matters.

The knowledge

The last item is the one nobody itemizes. How does the thing work? Where does it run? What breaks first? What is the recovery step when the nightly job does not run?

This does not need to be a manual. A short written runbook covering how to deploy, how to restore, what the scheduled jobs do, and what each external integration expects is usually a few pages, and it is the difference between a new developer picking up your system in a day and picking it up in a month. Ask for it as a deliverable, in writing, at the start. Documentation written at the end of a project is written under time pressure by someone who has already moved on.

The test that settles all of this

There is one question that collapses the checklist into something you can ask in a meeting, and it is more useful than any clause.

If our builder disappeared on a Tuesday, what would it take to keep this running?

A builder who has been doing this a while has a plain answer: your accounts, here is the runbook, the code is in your repository, here is the credential inventory, and any competent developer could take it from there. A builder who has never thought about it will answer with reassurance instead of specifics. That difference is diagnostic, and it costs you nothing to find out early.

Ask it during scoping, not during a dispute. During scoping it is a professional question about continuity. During a dispute it is a demand, and the answer takes months.

What belongs in the agreement

You do not need a long contract. You need a short list of things stated plainly, ideally reviewed by a lawyer who has read more of these than you have.

  1. Assignment of intellectual property. Ownership of the deliverables transfers to you, in writing, signed. Tie it to payment if you like, which is fair to both sides, but make the trigger explicit.
  2. Accounts in your name. Every third-party service the system depends on is opened under your business, with the builder given access. Where that is not possible, the exception is named in the agreement.
  3. Third-party components disclosed. Nearly all modern software includes open-source libraries, which is normal and good. What you want is a list, so you know what licenses you have inherited. Some licenses carry obligations if you later distribute the software.
  4. Handoff deliverables. Source code in a repository you control, the credential inventory, the runbook, and a data export. Named as deliverables, not as favors.
  5. Exit terms. What happens at the end, whether the end is amicable or not. How much notice, what gets handed over, in what timeframe, at what cost if any.

That is the whole list. Five items, none of them adversarial, all of them cheaper to agree on before work starts than after.

When a builder pushes back, and when that is fair

Not every pushback is a red flag, and it helps to know which is which.

Reasonable: a builder who keeps ownership of their own general-purpose tooling and internal libraries, the reusable parts they bring to every project, while assigning you everything specific to your system. That is standard, and it is how you get the benefit of work they have already done. What you want in that case is a perpetual license to use those components in your system, so a carve-out never becomes a leash.

Also reasonable: a builder who declines to hand over credentials to their own infrastructure, in an explicitly hosted arrangement, as long as your data and your custom code still come to you on request.

Less reasonable: holding your domain, refusing an export of your own data, declining to name what is carved out, or treating the exit conversation as an insult. None of that requires an argument. It is simply information about how the relationship ends, delivered before you commit to it.

AI systems have their own version of this list

If what you are commissioning is an AI system rather than a conventional application, the same principles apply with a few additions that are easy to miss because they do not look like software.

We wrote separately about what an AI system costs after it ships, and ownership is the quiet variable underneath that whole discussion. A system nobody can take over is a system that gets abandoned when the person who built it moves on, no matter how well it worked on the day it launched.

How we think about it

We are on the builder's side of this table, so it is fair to say where we stand. Elorati / Studio work is scoped in plain language, priced before we start, and the deliverables include the things above: the code in your repository, the accounts in your name, a runbook, and an assignment you can hand to a lawyer. Elorati / Managed exists for operators who would rather we keep running the system, and it is built on the same footing, because a maintenance arrangement should be something you continue by choice rather than by lock-in.

That is not generosity. A client who could replace us next quarter and does not is the only honest signal that the work is worth what it costs. The rest is just paperwork done early.

If you have systems running today that you have never checked against this list, the useful next step is not a renegotiation. It is an inventory: what runs where, in whose account, with whose keys, and who else could pick it up. Most of the time that inventory turns up two or three items to fix, and fixing them while everyone is on good terms takes an afternoon.

Frequently Asked Questions

If I paid for the software, do I own it?

Not automatically, at least not in the copyright sense. In the United States, copyright vests initially in the author, and the work made for hire exception for commissioned work covers nine specific categories that do not include software. Ownership moves through a written, signed assignment. Payment alone does not transfer copyright, which is why your agreement should say so explicitly rather than relying on the phrase "work for hire." Have a lawyer review the language for your situation.

What should I ask for at the end of a project?

Five things: the source code in a repository your business controls, an inventory of the accounts and credentials the system depends on, a short runbook covering deployment, recovery, and scheduled jobs, an export of your data in a usable format, and a signed assignment of the intellectual property. Ask for these as named deliverables at the start of the project rather than as requests at the end, when the team has already moved to other work.

Is it a problem if my developer hosts everything on their own accounts?

Only if it was never discussed. Some builders run client systems on their own infrastructure deliberately and price it as a hosted service, which is a legitimate arrangement. What makes it safe is disclosure and an exit path in writing: what happens to your data and your service if you stop working together, how much notice each side gives, and what gets handed over. The failure mode is not hosting, it is hosting nobody agreed to.

We already have a system running and none of this was set up. What now?

Start with an inventory rather than a legal conversation. List every account the system touches, note whose name is on each, find out where the credentials live, and try an actual data export. That usually surfaces two or three fixable items, and moving an account or adding an owner is routine when the relationship is good. Then paper the ownership question going forward, before the next piece of work starts.

This guide provides educational information based on industry research and case studies. Individual results vary by market, budget, and execution.