Most website disputes are not about money or quality. They are about the day somebody wants to leave and finds out what they actually own.

It is worth ten minutes before you hire anyone, because every piece of this is cheap to get right at the start and expensive to fix afterwards. What follows is how I do it, stated precisely — including the part that stays mine.

The three piles

Everything in a website project falls into one of three groups, and the mistake people make is assuming it is all one.

Three cards sorting the parts of a website project into what is yours outright, what is yours with the developer added, and what is licensed
The mistake is assuming it is all one pile. Sort it before you hire anyone, not after.

Pile one: yours outright, in your name

Your domain. The single most important line in this article. A domain registered to your developer is a hostage, however friendly everyone is today. Registered to you, it never is. Buy it yourself, from a registrar that sells at cost, and add your developer as a user with the access the work needs — step-by-step guide here.

Your Google Business Profile. Free, yours, and the thing that decides whether a local customer finds you at all. Your developer should be a Manager, never an Owner. Guide here.

Your Stripe account. Money goes from your customer, through Stripe, into your bank. It should never route through anyone else's account. Guide here.

Your content. Words, photos, logo, video. Yours before, during and after.

Your customer data. Enquiries, bookings, orders, subscribers. This is the asset the site exists to build, and it is yours. My privacy policy says it in the plainest words I could write: "That data is yours, not mine. I do not use it for anything other than the work you have asked for, I do not copy it elsewhere, and it leaves with you when the work ends."

Pile two: yours, held in accounts you own, with me added

The services the site needs to run — the domain registrar, the payment processor, the email sender. You create them, in your business's name, with your own email. I get invited with the narrowest role that does the job, and you can remove me in two clicks from the same screen you added me on.

This is the arrangement that makes leaving boring instead of dramatic. Nobody has to hand anything over, because nothing was ever in the wrong name.

Pile three: the code, which is licensed to you

Here is the part that most people never ask about and some developers are vague on, so I will be blunt about mine.

The site's code is licensed to you to use, and it stays mine. It runs on infrastructure I manage. That is what keeps the price where it is: I am not building each site from nothing, and I am not handing over a codebase that then has to be supportable by strangers. It is also what lets me fix something at nine on a Sunday without asking anyone's permission.

What that means in practice:

  • You are not buying a copy of the software to take to another developer.
  • You are buying a site that runs, is maintained, and whose every word, photo and price you control.
  • Your domain, content and data are unaffected by any of it — they are in pile one, and they leave with you.

If what you need is a codebase you own outright and can take anywhere, say so on the first call. It is a different kind of engagement and a different price, and I would rather establish that up front than discover it in year two. It is also not what most people are really asking for. What a business actually needs is that the site works, that it is theirs to edit, and that nothing about it can be held over them — and all three of those are already true above, without anybody having to maintain a codebase they cannot read.

What "you own your website" usually means

It is worth knowing that almost nobody means "you own the code" when they say this, including the platforms.

On Squarespace, Wix or Shopify you own your content and your data. You do not own the software, you cannot take it with you, and if you stop paying the monthly fee the site goes off. That is not a scandal — it is what a platform is.

The distinction that actually matters to your business is not who holds the copyright on a React component. It is:

  1. Can I still be found tomorrow if this relationship ends? (Domain, profile.)
  2. Can I still get paid? (Stripe.)
  3. Do I still have my customers? (Data.)
  4. Do I still have my words and pictures? (Content.)

Get those four right and the code question stops being frightening.

How leaving actually works, with me

Plainly, because a promise that only works while everyone is happy is not worth much.

  • Your domain is already in your name. Point it wherever you like.
  • Your accounts — registrar, Stripe, Google — are already yours. Remove my access from the same screen you granted it on.
  • Your content and data come out as a single export file from the admin dashboard: content, articles, pages and every form submission. You can take that whenever you want, not just at the end. On the Plus and Pro Care plans I keep an off-site copy of it as well. A Starter build has no dashboard, so there is no button to press — ask me and you get the identical file, and you do not need a reason.
  • Your photos are yours, and I will send them back in their original form.
  • The site itself runs on my infrastructure, so it ends when the work ends — the same arrangement as every platform, where the site also goes off when you stop paying. The difference is what you walk away with: your address, your content and your customers, in a file, ready for whoever builds the next one.

There is no exit fee and no ransom step, because there is nothing left in my hands that you need.

What that means on a bad day

That last point is the one worth being blunt about, because it is the one people are right to poke at. Three versions of the bad day, and what each actually costs you:

You decide to leave. Take the export, point your domain somewhere else, remove my access. Your next developer starts with your content, your customers and your address already in hand. What they do not get is my code, so they rebuild the site — which is what they were going to do anyway, since developers rarely inherit somebody else's work without rewriting it.

You stop paying. Nothing is switched off by surprise. My terms say hosting may be suspended after reasonable notice on an unpaid invoice, and "reasonable notice" means what it sounds like: a warning, in writing, with time to do something about it. The export is available that whole time, and every day before it — you do not have to ask me for it, and you do not have to be on good terms with me to get it.

I disappear. Hit by a bus, out of the business, whatever it is. Your domain is registered to you, your Google, Stripe and email accounts are yours, your photos are yours, and your content and customer list are in a file you already hold if you have ever pressed export. What you lose is the running site and my time — not your business's address, its history or its customers. That is the difference between a bad week and an emergency, and it is the whole reason the three piles are arranged the way they are.

And if none of that is good enough, say so on the first call. A codebase you can take anywhere is a different engagement and it costs more, because it is a different piece of work — but it exists, and I would rather quote it than have you sign something you are uneasy about.

The habit I would recommend with any developer, me included: press export once a month — or, with no dashboard, ask for the file once a month — and keep it somewhere you control. It takes a few seconds, and it turns every version of the bad day above into an inconvenience.

Seven questions to ask any developer

Ask these before you sign, and get the answers in writing.

  1. Whose name is the domain registered in? If it is theirs, why?
  2. Whose Stripe account do payments land in?
  3. Can I export my customer data, on my own, today? Not "will you send it to me" — can you do it yourself.
  4. What happens to the site if I stop paying? For a licensed or hosted arrangement the honest answer is "it stops." Make sure you have heard it.
  5. Do I get the code? Yes or no. Both are acceptable answers; vagueness is not.
  6. What is the hosting actually costing, and what am I being charged?
  7. Who owns the photos? If a photographer shot them, check what the licence covers — this one catches people out years later.

Where mine is written down

My answers are not a handshake. They are published:

  • The hire page states that your domain, content and customer data stay yours, and that the code is licensed to you while the site runs on infrastructure I manage.
  • The privacy policy states what happens to your customers' data, including that it leaves with you.
  • The terms state that published prices are starting prices, that nothing binds either of us until you have accepted a written quote, and that each project's own written agreement takes precedence over anything on the site.

If you are reading this while evaluating somebody else, the test is not whether they say the right things on a call. It is whether you can find them written down before you ask.