A garage owner rings on a Monday morning. He wants one thing changed: the opening hours on his own website. Small job. Except the person who built the site three years ago has stopped replying, the domain renewal invoice goes to that person's company, and nobody at the garage knows where the website actually runs.

Nothing was stolen and nobody acted in bad faith. The garage simply never owned the things it had been paying for.

This is the most common way a small IT project fails. Not in the first month, when everyone is enthusiastic, but two or three years later, when you want to change supplier, change direction, or just change your opening hours.

Five things that decide whether you can walk away

Ownership sounds like a subject for lawyers. In practice it is five very concrete things, and you can check all five in an afternoon.

The domain name. Whose name and email address is yourbusiness.co.uk registered to? Not "who set it up", but who is listed as the registrant, who receives the renewal invoice, and who can log in to move it. If that is your developer, your address on the internet belongs to someone else.

The hosting. The account where your site or app actually runs, and the card it is billed to. It is perfectly fine for your supplier to manage it. It is not fine for you to have no way in.

The code. The repository — the place where the source files live, along with the history of every change. You should be an owner or admin of it, even if you never open it.

The data. Customers, orders, bookings, invoices, photos. This is the only part you can never rebuild.

The connected accounts. The payment provider, the mailing tool, the analytics, your Google Business Profile, the Apple and Google developer accounts if you have an app. These are the easiest to lose, because they are usually set up in a hurry by whoever happened to be at the keyboard.

"You get the source code" is not the same as owning it

A zip file on a USB stick is technically the code. It is close to useless if nobody can tell you how to run it, which version is live, or why there is a folder called final-v3-new.

What you actually want is access to the repository with its history, a short written description of how the project is built and published, and one clear line in the quote. Something like:

All code, designs and content created for this project become our property on final payment. Accounts for the domain, hosting and connected services are created in our name. On request, the supplier provides access and a written description of how the project is run and published.

Ask for that paragraph at the quote stage and it costs nothing. Ask halfway through and it is a negotiation. Ask after a falling-out and it is a solicitor. A supplier who has no problem with it is telling you something useful — and so is one who does.

Your data is not the same thing as your website

A website can be rebuilt in a few weeks. Eight years of customer records cannot be retyped.

So test the exit once, while everyone is still friendly: can you, yourself, today, export your customers, orders and bookings into an ordinary file — CSV or Excel — without asking anyone for help? If the answer is a screenshot or "I'll ask the developer", you have just found your first job. While you are at it, ask one practical question about backups: where they run and how long they are kept. One sentence in an email is enough.

Owning it also means being reachable

In our experience the other half of the problem sits in a mailbox. The domain was properly in the company's name, but the renewal reminder went to the personal address of someone who left in 2023. For every account that can expire, use a shared address the business actually reads: accounts@, info@, office@.

Keep one page alongside it: which account, which provider, which email address, what it costs per year. A dull shared document that is correct beats a clever system nobody maintains. That single page is what turns changing supplier into an ordinary, mildly annoying decision instead of a crisis — which is exactly what it should be. When we hand a project over at ITSysPro, that list and a short how-it-runs document are part of the delivery; a client who can leave usually doesn't want to.

What to do this week

  • Find out who is listed as the registrant of your domain and which mailbox receives the renewal invoice. One email to your supplier will do it.
  • Export your customer or booking data yourself, today, into a file you can open, and save it somewhere you control.
  • Start that one page: domain, hosting, code, data, connected services — with provider, email address and annual cost.

If you would like to walk through your own list once with someone who has seen a few handovers, we are happy to have that conversation, with no strings attached.