Ivara Labs
Vendor lock-in rarely announces itself. It shows up the day you want to move, when it turns out the code is yours but the cloud accounts, the domain, the payment keys and the deployment tooling are still held in the builder’s name.
This piece is not about price. It is about custody: who holds the accounts your system runs on, who can revoke access, and whether you could keep operating if the vendor relationship ended tomorrow. Ownership language in a contract is only as strong as the account list behind it.
Ownership is a bundle, not a thing
Here is the ledger. For each item, what real ownership requires, and what "you own it" commonly means instead.
| Item | What ownership requires | What often happens instead |
|---|---|---|
| Copyright | A signed assignment of IP | A work-for-hire clause that does not cover software |
| Repository | Your git organisation, full history | A zip of final source, no commit history |
| Cloud accounts | In your legal name, your billing | The vendor's account, "for convenience" |
| Third-party keys | Your Stripe, your API accounts | The vendor's keys, shared with you |
| Dependencies | Public or owned code only | The vendor's private framework, licensed while you pay |
| Documentation | Runbooks, architecture, decisions | Knowledge in one builder's head |
| Data | Exportable in a documented schema | Exportable in theory, undocumented in practice |
Any single row left in the right-hand column is enough to make the other six academic.
The copyright default that surprises people
Start with the one most commonly got wrong, because it is counterintuitive and it is settled law.
In the United States, paying someone to write software does not give you its copyright. Absent a signed assignment, the contractor who wrote it owns it. You have paid for a deliverable and received, by default, an implied licence to use it.
17 U.S.C. § 101Many contracts try to solve this with a "work made for hire" clause. For an independent contractor, that clause only works if three conditions hold: the work was specially commissioned, there is a signed written agreement, and the work falls into one of nine enumerated categories in the statute.
Software is not one of the nine. It is a literary work under § 102, and literary works are absent from that list. A work-for-hire clause covering custom software is, on its own, frequently ineffective — which is why the operative language you want is an express assignment of all right, title and interest, not a work-for-hire recital.
Canada arrives at a similar place by a different route. The author is first owner. An employer owns what employees create in the course of employment, but a contractor is not an employee, so an assignment in writing is required. One extra wrinkle: moral rights cannot be assigned in Canada at all — they can only be waived, and a contract that assigns copyright without a moral rights waiver has left something on the table.
A licence is permission. An assignment is ownership. Contracts that use the first word while the sales call used the second are not an accident.
Where ownership quietly leaks
Accounts held in the vendor's name
This is the most common leak and the least deliberate. During a build it is genuinely faster for the vendor to spin up hosting, the database, the email sender and the payment account under their own organisation. Nobody intends it to be permanent. Then the build ships and nobody migrates it.
The contract can say you own everything. If the production database sits in the vendor's cloud tenancy and the domain is on their registrar account, your ownership requires their cooperation to exercise. That is not ownership. That is a good relationship.
The vendor's own framework
This one is subtle, and it is the trap most worth checking for. A vendor with an internal accelerator — their own component library, their own admin scaffolding, their own deployment tooling — builds faster because of it. Reasonable. But if that layer stays proprietary and you receive only a licence to it, then "here is your code" hands you an application that will not compile without something you do not own.
Ask directly: if we forked this today and never spoke to you again, does it build? The answer is either yes or a negotiation.
Documentation that was never a deliverable
Undocumented software you legally own is software only its author can operate. As we put it when comparing this to subscription costs in why per-seat pricing becomes a tax on growth, that trades vendor lock-in for key-person lock-in — the worse of the two, because a key person can resign and a vendor cannot.
The test that settles it
If this vendor vanished tomorrow, does everything you paid for keep running — and can somebody else maintain it?
- Can you log into every account the system depends on, without asking anyone?
- Can a new developer clone the repository and get it running locally from the documentation alone?
- Can you deploy a change without the vendor's tooling or credentials?
- Does the build succeed using only code you own or code that is publicly available?
- Can you export your data in a schema somebody else could read?
- Do you hold a signed assignment, not a licence?
Six yeses is ownership. Anything less is a subscription with better wording, and the honest thing is to price it as one.
The test is also the right thing to run before signing, phrased as questions to the vendor. A builder who has done this properly will answer all six without hesitation, because they designed for it. One who has not will explain why the question is unusual.
Language worth stopping on
Phrases that sound like ownership and are not
- "You'll have full access to the code"
- Access is not ownership. You can have complete access to something you have no right to modify, fork, or take to another developer.
- "Perpetual, irrevocable, worldwide licence"
- Impressive adjectives on a licence. Still a licence. The vendor remains the owner and can license the same work to anyone else, including a competitor.
- "Work made for hire"
- Frequently ineffective for software written by a contractor in the US. You want an express assignment clause alongside it, not instead of it.
- "Source code escrow"
- A fallback, not ownership. Escrow releases code on defined trigger events, usually the vendor's insolvency. It does nothing about accounts, documentation, or the right to modify.
- "Built on our proprietary platform"
- Worth a direct question about what happens to that layer if you leave. Sometimes the answer is fine. It should be an answer, not an assumption.
When you should not want ownership
Ownership is not automatically the right thing to want, and any builder telling you it always is has an interest in the answer.
A managed arrangement is the better call when
- You cannot operate it. Owning infrastructure you have nobody to run is a liability with a nice clause attached. Ownership assumes capability, or a plan to acquire it.
- The system is commodity. You should not own your payroll engine or your email platform. Differentiation is the reason to own something.
- The process is still moving. Encoding an unsettled process produces something you own and immediately need to rebuild.
- You genuinely want it to be someone else's problem. That is a legitimate choice. It just needs to be a choice, priced as one, rather than a surprise discovered at renewal.
The point is not that everything should be owned. It is that you should know which of the seven items you hold, and have decided the rest deliberately.
Where we stand on this
The platform, the code and the accounts sit in your name from day one, and documentation ships with every build so a future hire or an internal team can take over without us in the room. If we disappeared tomorrow, everything you paid for keeps running.
That is written down as one of our standards rather than said on a call, and it is the reason we do not rent custom builds back to the people who paid for them. If you would rather subscribe, that stays available — the difference is that leaving remains possible either way.
If you already have a build and are not sure which column of that ledger you are in, run the six questions against it. If the answers are uncomfortable, that is worth knowing now rather than at renewal. Tell us what you are running and we will give you a straight read.
Frequently asked questions
- If I pay a developer to write software, do I own it?
- Not automatically. In the US, copyright in work by an independent contractor stays with the contractor unless there is a signed assignment. Canada reaches the same result for contractors: an assignment must be in writing. Paying an invoice is not an assignment.
- Does a work-for-hire clause cover custom software?
- Often not. For contractor work, the work-made-for-hire route requires the work to fall within one of nine enumerated statutory categories, and software is not among them. An express assignment of all right, title and interest is the reliable mechanism.
- What is the difference between a licence and ownership?
- A licence is permission to use something someone else owns, however long and broad the wording. An assignment transfers the right itself, including the right to modify, fork, hand to another developer, or sell.
- Is source code escrow the same as owning the code?
- No. Escrow is a contingency that releases code on defined trigger events such as vendor insolvency. It does not give you ownership, accounts, documentation, or an unrestricted right to modify.
- How do I check whether I really own a build?
- Run the disappearance test: log into every account unaided, clone and run the repo from documentation alone, deploy without vendor credentials, build using only code you own or that is public, export your data in a documented schema, and confirm you hold a signed assignment rather than a licence.
This article is general information about how software ownership commonly works, not legal advice. Contract terms and copyright law vary by jurisdiction and by agreement. Have a lawyer review the actual language before you sign it.