Who owns the code and the database when someone builds your system?
The answer that matters is not in the contract's intellectual property clause. It is in what stops working the day you stop paying.
The short answer
You should own the repository, the database, the domain and the payment account outright, with no per-seat licence back to the studio and nothing that switches off if you leave. Orium builds it that way: third-party services are billed in your name, and the next developer inherits a normal project. Ask any vendor one question first, which is exactly what stops working the day you stop paying them.
SHT-02What drives the number
Ownership is five separate things, not one
A vendor can say you own the code and be telling the truth while still holding everything that makes the code useful. Count them separately. The repository: is the source in an account you control, and can you invite a different developer to it tomorrow without asking permission? The database: is the project in your organisation, with your billing card, and can you take a full backup right now? The domain and DNS: is the registrar account yours? The payment account: when a customer pays you, does the money land in your own merchant account, or in the vendor's and then get forwarded? And the third-party services: hosting, email, telephony, model providers, each of which is either an invoice in your name or a line item on the vendor's bill with an unknown margin on top. Ownership means all five. Four out of five is a hostage situation with good manners.
The licence back to the studio, and why it is the expensive one
The common structure is that you pay for a build and then pay a monthly per-seat fee to use what you paid for. It is presented as support, and support is a real thing worth paying for, but a per-seat fee is not support: it is rent on your own asset, and it is the line that grows every time you hire. The version of this that hurts most is the one nobody reads until later, where the vendor keeps a licence to the platform your system runs on. Your code sits on top of it, and the code is genuinely yours, and it does not run anywhere else. Nothing here is licensed back. A team growing from four people to nine does not change what was paid.
The questions to ask, and what a bad answer sounds like
Ask these plainly and write down the answers. What exactly stops working the day I stop paying you? Whose name is on the hosting, database and payment accounts? Can I add a developer of my choosing to the repository this week? If I ask for a full database backup right now, how long until I have it? Is any part of this built on a platform you license, and what happens to my system if you stop licensing it? Is there a per-user fee, now or at any headcount? A good answer is short and specific. A bad answer has a shape: it redirects to how unlikely leaving is, it explains that ownership is complicated, it offers a source code escrow instead of the source code, or it answers a different question about how much they care about clients. Vagueness here is not modesty. It is the answer.
What a clean handover actually contains
A repository you can clone is the beginning, not the end. The handover has to include the schema as an ordered set of migrations, so the database can be rebuilt from scratch rather than only copied, and so the next developer can see when each rule arrived and why. It includes the test suite, because tests are how a stranger changes your code without breaking the part that makes you money. It includes the environment variables documented, so nobody has to guess which key is which. Across the three systems in production that shape means 557 automated tests, 352 database migrations and 13 guard tests that read the source rather than the output. The point of all of it is that a developer who has never met me can pick this up and be productive, which is only a benefit to you if you might one day want exactly that.
Why a studio would give this up, and what it costs them
It costs the studio the safest revenue there is. A per-seat licence is money that arrives whether or not anyone does anything, and giving it up means every month of a retainer has to be earned again by being useful. That is the trade, and it is deliberate rather than generous: a client who cannot leave is a client nobody has to keep happy. It also changes what gets built. When the money in your Stripe account is yours from the first transaction, the fee arithmetic has to be right in whole cents, because the numbers land in a bank account with your name on it rather than in a platform balance nobody reconciles.
SHT-03The options, side by side
What each route actually costs you.
| Option | Price | Timeline | The trade-off |
|---|---|---|---|
| SaaS product subscription | Per seat, per month | Same day | You own your data and nothing else, by design and honestly stated. Check the export format before you sign; a CSV of contacts is not your history. |
| Agency build on a licensed platform | Build fee plus platform licence | Months | The code is genuinely yours and runs in exactly one place. Leaving means rebuilding, which is the reason the arrangement exists. |
| Build with a per-seat fee back to the builder | Build fee plus per-user monthly | Varies | You paid for the asset and now rent it. The bill grows with every hire, in the year you are hiring, which is the year you have least room for it. |
| Orium Studios | From $2,000, no per-seat fee | 30-45 days | Your repository, your database, your domain, your payment account, providers billed in your name. Nothing switches off if you leave, so the studio has to stay worth keeping. |
SHT-04General notes
The questions people actually ask.
- N01Who owns the code when an agency builds a CRM?
- It depends entirely on the contract, and the default in the market is not in your favour. Ownership should cover the repository, the database, the domain, the payment account and the third-party services, all in your name. If any of those sit with the vendor, you have possession of the code without control of the system.
- N02What is the single best question to ask a vendor?
- What exactly stops working the day I stop paying you. A vendor with a clean structure answers in one sentence: nothing does, and here are the accounts, all in your name. Anything longer than that is worth reading carefully.
- N03Is source code escrow good enough?
- It is better than nothing and much worse than the source. Escrow gives you a copy of files under conditions that have to be triggered and argued, usually at the worst possible moment. Being an owner of the repository today means you can hand it to another developer this week without anyone's cooperation.
- N04Do I own the database as well as the code?
- You should, and they are separate questions. The database project should be in your organisation on your billing, so you can take a full backup at any time without asking. Ask for one during the build rather than after, because the time to discover you cannot get it is not the day you need it.
- N05What about third-party services like hosting and telephony?
- Those accounts are yours and billed directly to you. It means you see the real cost with no margin added, you can change providers, and the invoices arrive in your name. It also means somebody in your business has to notice when a card expires, which is a fair trade for not renting your own infrastructure back.
- N06If I own everything, why would I keep paying a retainer?
- Only because it is worth it. Retainers run at $300, $750 or $1,500 a month depending on how much continuing change the business generates, and a system that needs none is a legitimate outcome that gets said out loud. Nothing switches off if you stop, which is exactly what makes the decision an honest one each month.