Owning the source is roughly one of seven things you need. Without repository history, deployment and app store accounts, domain and DNS, third-party services in your own name, a secrets inventory, dependency licences and an express IP assignment, you can hold the code and still be unable to run or change your product.
Ask any software vendor whether you will own the code and they will say yes. It has become a box to tick rather than a commitment, partly because the sentence sounds complete and is not. Owning the source files is genuinely necessary. It is also the easiest of the things you need, and on its own it will not let you leave.
The practical test is not "do I have the code." It is: if this vendor disappeared tomorrow, could a different engineer run, change and deploy this product? Here is what that requires.
The seven things
| What | Why it matters | Failure mode if you skip it |
|---|---|---|
| Source, with history | The repository transferred to your organisation, commits intact | A zip file with one commit: no history, no context, no idea why anything is the way it is |
| Deployment accounts | Hosting, CI, DNS — in your name, your billing | The site goes down and only your vendor can log in |
| App store accounts | Apple and Google, your company, vendor added as a member | Your app lives under someone else's publisher identity |
| Third-party services | Payments, email, analytics, model APIs — your accounts | Your customer data sits inside a vendor's account |
| Secrets inventory | A list of every environment variable and where it comes from | A working codebase nobody can start |
| Dependency licences | What open-source is in there and under what terms | A copyleft obligation discovered during due diligence |
| IP assignment | Written, present-tense, effective on payment | You possess the files; someone else holds the copyright |
The one people get wrong: intellectual property
Possession is not ownership. Copyright in code vests initially in whoever wrote it, and it moves to you only if a contract moves it. A great many agreements say something vague like "the client shall own the deliverables" without an operative assignment clause, which is a description of intent rather than a transfer.
Two things worth knowing without needing a law degree:
- "Work for hire" is not a magic phrase. It is a specific US copyright concept, it does not automatically cover most independent contractor software work, and it has no clean equivalent in many other jurisdictions. A contract relying on it alone may not do what both parties assumed.
- Ask for an express assignment — present tense, effective on final payment, covering source, designs and documentation. "Assigns" is a transfer. "Will assign" is a promise to do something later, which is a different and weaker thing.
This is general orientation, not legal advice — for anything material, have a lawyer read the clause. But knowing which clause to point them at is most of the value.
The one that bites soonest: accounts
Intellectual property disputes are rare. Account lock-in is routine, and it usually is not malice — it is convenience that hardened. The vendor set things up on their own accounts because it was faster on day one, and nobody revisited it.
The consequences arrive at the worst moments. An app published under a vendor's Apple account cannot be moved without their active cooperation, and even a cooperative transfer is slow. A domain registered in a vendor's name is a hostage nobody intended to take. Analytics and payment accounts under their login means your customer data is somewhere you cannot audit.
The fix costs nothing if done at the start: every account in your company's name, billed to your card, with the vendor invited as a member. Insist on it in week one. Retrofitting it later is tedious in every case and impossible in a few.
Licences: the quiet one
Every modern application includes open-source dependencies, and that is entirely normal. The licences mostly do not constrain commercial use — MIT, Apache 2.0, BSD and similar are unproblematic for typical products.
The ones worth knowing about are copyleft: GPL and, for anything served over a network, AGPL, which can attach obligations to code you distribute or expose as a service. This rarely becomes a problem in practice. It becomes an expensive problem at exactly one moment: due diligence during an acquisition or a funding round, when someone runs a licence scan and finds something nobody had looked at in three years. Ask for the dependency list at handover, once, and the question is closed.
What good handover looks like
At the end of a Norward project you get the repository with its full history in your organisation, every account already in your name because they were set up that way from week one, an inventory of environment variables, the dependency list, deployment documentation, and written confirmation that IP transfers on final payment. Not because it is generous — because lock-in as a revenue strategy is a business model we would rather not have.
Book a free 30-minute discovery call. Every engagement ships with full source, tests and documentation in a repository you own — and accounts in your name from week one.
Book a free discovery call