Who controls it

A restaurant's online presence was created by Inès, its manager at the time. She opened the Instagram account, the Google listing that shows the opening hours and the reviews, and the account of the booking tool, all with her personal email address. The restaurant paid every bill. Then Inès moved to another city.

Six months later, the owner wants to change the opening hours on Google. He can't, because the listing belongs to Inès's account. A bad review needs an answer, and nobody can post it. The booking tool's renewal emails go to an inbox that nobody reads any more.

On the web, control follows the account, not the invoice. Whoever holds the account decides what happens: they can renew it, change it, give access to others, or close it. They can also let it expire, lock the organisation out, or ask for money to hand it over. Paying the bills doesn't put your name on the account. And proving that the asset is yours can take weeks of emails with the provider's support.

Nothing goes wrong while everyone is around and on good terms. It goes wrong when a card expires, a contract ends, a person leaves, or a relationship turns bad.

The best moment to fix ownership is before anyone leaves: at a handover, at the end of a contract, or simply today, while everyone can still be reached and is on good terms. Once a person has left, or a freelancer has stopped answering, every transfer becomes slow and uncertain.

For each account that the site depends on, do four things. Move it into the organisation's name, paid with the organisation's card. Link it to a shared address that the next team inherits, not to one person's email. Give admin access to at least two people, each with their own login. And write it in a list: what the account is for, who owns it, what it costs, and when it renews.

Some moves take time. Moving a domain name from one person's account to another needs a transfer code from the current holder's account, and it can take several days. So don't wait for the renewal date.

With a freelancer or an agency, write ownership into the contract before the work starts. The accounts, the code and the data belong to the client, and they are handed over at the end. Then check that they really were, before you pay the last invoice.

The example below shows the list for a small dance school's site, before and after its handover. Before, the accounts belonged to people, and one of them had left. After, each account belongs to the school, uses the school's address and card, and has two admins.

A launch has a project manager, a deadline and everyone's attention. The years after the launch usually have nobody. Without a named owner, things don't break loudly. They break quietly.

Take a tourist office that launches an audio guide: visitors scan a code next to each sight and listen on their phone. After the launch, the money and the attention move on to the next project. A year later, the card that paid for the hosting has expired, and some pages are offline. A phone update has broken the audio player on recent iPhones. Two new sights have no audio. Nobody notices, because nothing looks broken from the office. Visitors just stop scanning.

So before launch, name an owner: a person inside the organisation whose job includes this service, with time and a budget for it. The owner doesn't need to be technical, but needs a few habits. Send a test message through the form now and then. Read the alerts and the bills. Check that the content is still true. And know who fixes problems: someone in-house, or a provider under a maintenance contract.

Have alerts and messages sent to a shared address, so that a holiday or a departure doesn't stop them. Give each departure a handover. And plan the end. When the service is no longer used, the owner decides to close it and delete its data, instead of leaving it online and forgotten.

Every provider is easy to start with. The risk is lock-in: your site, your data or your tools only work with this provider, so leaving means rebuilding. And the provider knows it. Prices can rise, the service can get worse, the company can be bought or close, and you can't negotiate, because leaving would cost months of work.

The lesson Build or subscribe asked whether you can take your data with you. Here are the other questions to ask before signing, while you still have a choice:

• Can we export our data, and in what form? A training company that builds 40 courses inside one e-learning platform should check that the courses, the learners and their results come out in files that another tool can read.
• What do we own? The content, the design, the code, the domain name. If it isn't written down, assume that you don't own it.
• What would leaving cost, and how long would it take? Ask other customers who left.
• What happens if the provider raises its prices or closes?

Lock-in isn't always a mistake. A platform that saves months of work can be worth depending on, if the choice is made knowingly and the cost of leaving is known. Two habits make leaving possible. Keep the domain name in your own name, so that you can send visitors to a new site. And write the exit into the contract: your data and code returned at the end, notice before any change, and limits on price increases.

Ask these questions at the start of a project, before signing with a provider, and at every handover.

Ask for the list of every account that the site and its tools depend on: the domain, the hosting, the email, the social media, the analytics, the code, the payment and booking tools. For each one, ask whose name it's in, which card pays, which address receives its emails, and who else can log in. Move anything held by one person, a freelancer or an agency into the organisation's name now, while everyone can still be reached.

Before launch, ask who owns the service afterwards, with how much time and what budget. Ask who watches it, who fixes it, and who users contact. Ask what happens when that person is on holiday, or leaves.

Before signing with a provider, ask how you would leave. What can be exported, and in what form? What do you own? What would it cost? Write the answers into the contract.

For your portfolio, the domain, the hosting, the GitHub repository and the form service should all be in your own name. Link them to an email address you'll still use in five years, not your school address, which will close after you graduate.