What you actually own when the project ends

There is a question almost nobody asks before signing, and it decides how much control you have for the entire life of the thing you are buying. When this is finished, what do I own?

It matters most at the worst moment. If the relationship ends badly, or the studio closes, or you simply want to work with somebody else, the answer determines whether that is an inconvenience or a catastrophe.

The domain is the one that ruins people

Your domain name should be registered in an account that belongs to you, with your email on it, paid by your card.

This is the single most common trap in the industry and it is usually not malicious. A studio registers the domain during setup because it is faster than waiting for the client to do it, everyone gets on with the project, and nobody thinks about it again. Then two years later the client wants to move and discovers that the address their customers know, the address on their van and their business cards and every invoice they have ever sent, is legally somebody else's property.

A cooperative studio transfers it in an afternoon. An uncooperative or unreachable one leaves you with almost no options, because a domain is not something you can rebuild. Everything else on this page can be recreated given time and money. Your domain cannot.

Check this today, whoever built your site. Log in to the registrar. If you cannot, that is the answer.

The code

For custom work, you should own the source code outright, and the agreement should say so in words rather than leaving it to be assumed.

Two distinctions are worth understanding. Source code is what a developer edits. Deployed code is what the server runs, which for many stacks is a compiled or bundled version that is technically present but practically unusable for making changes. Being handed the second and told you have the code is not the same as owning it.

The other distinction is between what was built for you and what it was built with. Frameworks, libraries and open source components are not yours and do not need to be; they are freely licensed to anyone, including whoever you hire next. What matters is that the part written specifically for your project belongs to you, with no restriction on who is allowed to edit it later.

If a studio uses a proprietary in-house framework or a page builder with a per-site licence, ask directly what happens to your site if you stop working with them. There are honest answers to that question. There are also studios whose entire retention model is that the answer is bad.

The hosting account

Same principle as the domain, slightly lower stakes.

If your site is hosted under the studio's account, you cannot move it, you cannot see the bill, and if their account has a problem your site has a problem. Ideally the hosting is in your name and you grant access. That said, this is genuinely negotiable: bundled hosting is a normal, legitimate service, and for a business with nobody technical it can be exactly the right arrangement. It is only a problem when nobody told you.

We host projects on our own infrastructure under a care plan, and we think that is a good deal for the right client. It does not change who owns the domain or the code, and it should not for anyone else either.

The accounts around it

The list people forget. Analytics, the payment processor, the email service, the search console, any social profiles created during launch, the SSL certificate if it is not automatic, any third party the site depends on.

Every one of those should be in an account you control, with your recovery email on it. Access granted to the studio, not ownership held by the studio. It is the same fix in each case and it takes minutes at setup, which is exactly why it is worth insisting on at setup rather than untangling later.

The data

Your customer records, orders, enquiries, bookings and mailing list belong to you and, in an important sense, to the people they describe.

You should be able to export all of it in a format something else can read. Ask before signing, not after. A system you cannot get your data out of is a system you can never leave, and that is sometimes a deliberate design rather than an oversight.

The test

Forget the contract language and ask one question. If you hired a different developer tomorrow, what would you need from us, and could you get it without our cooperation?

If the honest answer is that you could hand someone the domain login, the hosting access, the code and a database export, and they could carry on, you own your project. If the answer involves needing us to agree, you do not, whatever the invoice says.

Why we split our own work the way we do

Our fixed projects are exactly this: you own it and you run it, no recurring fee, later work quoted when you want it. Our care plan keeps us hosting and maintaining the thing, monthly, for as long as it runs.

The reason we split by who operates it rather than by how you pay is that the second framing quietly encourages the trap described above. When the recurring revenue depends on the client being unable to leave, the incentive is to make leaving hard. When it depends on doing maintenance they would otherwise have to do themselves, the incentive is to be worth keeping.

You should still own your domain and your code under either one. If a studio ever tells you otherwise, that is the whole answer about that studio.