Who owns the code when an agency builds your software?
Don't assume the answer. Unless a contract says otherwise, the person who made the work may keep rights in it, even though you paid for it. That is why the contract matters more than the handshake.
This is general information, not legal advice. Have your own lawyer read anything you sign. What follows is a checklist of what to ask for, written from the builder's side of the table.
What does "ownership" actually cover in an AI project?
It is more than code. An AI project has six parts, and each can end up in someone else's hands.
| Part | What it is | What to ask for |
|---|---|---|
| Code | The software written for you | The rights to it, assigned to you in writing |
| Accounts | Hosting, repository, domain, AI provider, analytics | Every one opened in your name |
| Data | Your records, documents and anything produced from them | You own it, and it is not used to train anyone else's product without your say |
| Configuration | Prompts, rules, settings, workflows | Delivered and documented, not locked in a vendor's dashboard |
| Documentation | How it works and how to run it | Handed over with the code |
| Third-party parts | Open-source libraries, AI models, paid services | A list of them and their licence terms |
What should an AI project contract say about IP?
Ten clauses to look for, or to ask your lawyer about:
- Who owns the code, and from when? "On final payment" leaves you exposed in the middle.
- Whether the rights are assigned to you or only licensed.
- Which accounts are opened, and in whose name.
- Who owns your data and any output made from it.
- What the builder may reuse for other clients, and what stays yours.
- A list of third-party and open-source components and their terms.
- What the AI provider's terms say about your data.
- What a handover includes, and by when it happens if you part ways.
- Whether you can stop between stages, and what you keep if you do.
- Who is responsible if something in the build infringes someone else's rights.
Reuse deserves a second look. Builders carry know-how from job to job, and that is fine. What matters is that your code, your data and your business rules are not sold on or handed to someone else.
Why do accounts matter as much as code?
Code you can't run is of little use. If the hosting, the database and the AI provider account sit under the builder's login, they hold the keys. You can own the code on paper and still be unable to switch it on.
It is also a money question. If the builder holds the accounts, usage bills pass through them, and you can't see what is being spent. When the accounts are yours, you see every bill from the provider directly.
The test is simple. Ask: "If we stopped working together today, could someone else keep this running by tomorrow?" If the answer is no, you don't own it in any way that counts.
Why do we put everything in the client's name from day one?
Because it removes the argument before it can start. At Agentsy, the client owns every account, all data and all code, from day one. We open accounts in your name. AI usage and software are billed at cost, in your name. If we part ways, you get a full handover.
There is a practical benefit too. We work inside your accounts, so you can see the work as it happens. Nothing has to be moved across at the end, and moving is where things get lost.
If you are comparing partners, put this question to each of them. The full list of questions is in how to choose an AI implementation partner in Australia.
What does a good handover include?
- The code, in a repository you own.
- Admin access to every account and service the project uses.
- Your data, in a form you can read and move.
- The prompts, rules and settings, written down.
- Notes on how it is built, deployed and recovered.
- A walk-through with the people who will run it.
Ask to see the handover list at the start, not the end. A builder who is happy to show it is planning to leave you in a good place.
What are the red flags in an agency contract?
- Ownership passes only on final payment, with nothing said about the work in progress.
- The builder keeps the right to use your data for other purposes.
- Hosting, repository or AI provider accounts are held by the builder.
- Prompts, rules and settings live only in the builder's tools.
- Handover is "available on request" with no list and no timeframe.
- The contract is silent on third-party and open-source parts.
None of these is proof of bad faith. Most come from templates nobody revisited. They are still worth fixing before you sign, when it costs one email, and not after, when it costs a negotiation.
What about code that was written with AI or vibe coded?
The same questions apply, plus one: who has checked it? Code that came out of an AI tool still needs an owner, a review and a record of where it runs. If you already have a prototype built this way, check the accounts first. They are often tied to someone's personal login. Our vibe coding to production page explains how we turn prototypes into software you can rely on.
Once the ownership is clear, the build-or-buy question gets easier too. See build vs buy AI for how ownership changes the maths.