What you should own when a software project ends

A business rings us because it wants one change made to its website. A price has gone up, or a phone number has changed. The person who built the site three years ago is not answering, and the number we are given rings out.

Then the real problem appears. The domain is registered in that developer's personal account. The hosting is on their reseller plan, paid by them and invoiced to the business as a yearly fee. The code, if it exists anywhere outside the live server, is on a laptop we cannot see. The business has been paying for something it does not own for three years, and nobody was hiding it. It was just never written down.

The five accounts that belong to the business

1. The domain. Registered to the business, with a business email address as the contact, in an account somebody at the business can sign into. This is the most important line on the page. A site can be rebuilt and a server can be replaced, but a domain you do not control takes the website and every email address with it.

2. The hosting or server account. In your name, paid on your card. A developer's reseller account means your site lives inside somebody else's bill, and it stops when that bill does.

3. The code. In a repository owned by a business account, with the developer invited to it, rather than the other way round. The history matters as much as the current state, since it is what makes the next developer cheaper than the last one.

4. The third-party services. Payment gateway, mail sending, maps, analytics, SMS, error reporting. Each signed up with a business address rather than a personal one, because each is a way back into the system.

5. The data. Customers, orders, posts, files. With a documented way to take a full copy out, and at least one copy that has actually been taken and opened.

Access is not the same as ownership

An admin login to your own website is access. It can be revoked by whoever owns the account above it, and it disappears when a relationship ends badly or when a person stops replying. Ownership is the account the bill is attached to and the email address the password reset goes to.

The order to set this up in is simple and it only works before the work starts. The business opens the accounts. The business pays for them. The developer is added to each one with the access they need. When the project ends, that access is removed in an afternoon, and nothing else has to happen.

What a handover actually contains

Not a phone call and a folder of screenshots. Six things, and they are the same six every time.

• A list of every account, what it is for, who pays it, and the date it renews.

• The credentials, moved into the business's password manager rather than sent in a chat message that stays there for the rest of time.

• The repository, with its history, and a short file explaining how to run the project on a new machine.

• How a change reaches the live site: where it is deployed, what triggers it, and what to check when it will not start.

• A copy of the database and the uploaded files, plus the one command that produces the next copy.

• Anything that expires: the domain, the TLS certificate, API keys with an end date, a paid plan that will lapse.

That is half a day of work at the end of a project. It is the difference between a business that can hire anybody next time and a business that has to go back to whoever built it, at whatever price is quoted.

Ask for it before anybody writes code

Put it in the scope. One paragraph is enough: the accounts are opened in the client's name, the repository belongs to the client, and the handover pack above is delivered before the final payment. Any developer working straightforwardly will agree to that without a pause, because it costs them nothing and they were going to do it anyway.

A refusal, or a long explanation of why it is simpler their way, is information. It is usually about keeping the maintenance work rather than about anything technical. Simpler is a fair reason to hold accounts during a build. It is not a reason to hold them afterwards.

If you are already locked out

It happens often enough that there is a standard order to work through.

1. Start with the registrar rather than the developer. Registrars have a dispute process, and a business that can show its registration documents, its payment history and the original correspondence has a real claim to a domain registered on its behalf.

2. Gather the payment records first. Whoever has been paying the invoices for five years is in a much stronger position than whoever remembers a conversation.

3. Assume the rest can be rebuilt. Text and images can be recovered from the live site and from the Internet Archive. A design can be redrawn. It is annoying and it has a cost, but it is bounded.

4. Change the order next time. The domain is registered in your name, in your account, before a single line of code is written.

A handover is not a document produced at the end of a project. It is a set of accounts opened correctly at the beginning of one.

We put the handover in the scope of every build, because a system a client cannot walk away with is not finished work. What that covers is on the software development page. If you are in the middle of this now, tell us what you can and cannot sign into and we will tell you what is recoverable.