Cost & planning

Do You Really Own Your Website? Domain, Hosting, Code

You paid for the site, but is it yours? A practical check of the five things you need to own, and the handover list to ask your developer for.

In this article (10)
  1. The five things owning a website actually means
  2. The domain: the one you can't afford to lose
  3. Hosting: whose account, whose card
  4. Code: what "you own the code" should mean
  5. Data: students, orders and customers are yours
  6. Accounts: the quiet dependency
  7. Your handover checklist
  8. Common ownership mistakes
  9. Questions people ask
  10. Check it this week, not during a crisis

Imagine a physics teacher in Mansoura. It's the night before a big exam, and his platform won't load. The developer who built it isn't answering. The hosting account is under the developer's email. The domain renewal reminders have been going to an inbox the teacher has never seen.

He paid for the platform in full. But in every way that matters tonight, he doesn't own it.

This happens more often than it should, and almost never because someone was dishonest. It happens because "owning a website" sounds like one thing, when it's actually five. Here's how to check each one, and what to ask for before the next crisis rather than during it.

The five things owning a website actually means

LayerWhat it isRegistered toWhat you should have
DomainYour address, like yourbusiness.comYou or your company, with your email as the contactRegistrar login, expiry date, auto-renew on
HostingThe server that runs the siteYour account, or one you can move out of at any timeControl panel login, or a written right to a full backup
CodeThe files that make the site workYou, per the contract, for custom workA full copy of the files and database
DataContent, customers, orders, studentsYouA way to export it, and access to backups
AccountsEmail, Google tools, payment gateway, social pagesYou as owner, the agency as a userOwner-level logins for each

Now let's go through them one at a time, starting with the one that hurts most to lose.

The domain: the one you can't afford to lose

Your domain is on your business cards, your shop sign, your Instagram bio and every WhatsApp message you've ever sent a client. It's the hardest thing to replace.

Log in to the registrar account and check three things. First, the registrant: is it your name or your company's, and is the contact email one you control? Second, the expiry date and whether auto-renew is on with a working card. Third, whether you can request the transfer code (often called the auth or EPP code). If you can, you can move the domain whenever you want.

If a domain expires and isn't renewed, there's usually a short grace period, and after that it can be released for anyone to register, including a competitor or a reseller who'll offer it back to you at a price. Our guide to choosing and registering a domain covers extensions like .com, .eg and .sa in more detail.

Hosting: whose account, whose card

It's perfectly normal for a studio to host your site on its own server and handle the technical side. Many small businesses prefer it. The question isn't who manages hosting. It's whether you can leave.

Ask for a clear answer to this: "If I decide to move, will you give me a full backup of the files and the database within a few days, at no extra charge?" If the answer is yes and it's written down, managed hosting is fine. If the answer is hesitant, or comes with an "exit fee", your site is effectively rented. For the jargon behind plans and servers, see our plain-language hosting guide.

Code: what "you own the code" should mean

For a site built specifically for you, the contract should say that the rights to the custom work pass to you once it's fully paid, or at least that you get a permanent licence to use and modify it. We're not lawyers, and for a large project it's worth having one read the contract.

Two things are normal and shouldn't worry you. Any site uses shared building blocks: open-source libraries like Bootstrap (which is MIT-licensed), web fonts with their own licences, and sometimes paid components. You own your custom code, not those building blocks, and that's fine as long as their licences allow your use.

What you do need is the actual files. An admin login is not the code. Ask for the source files, a copy of the database, and a short note on how to deploy them. If the developer uses a Git repository, ask to be added to it.

Data: students, orders and customers are yours

Your customer list, order history and student records may be worth more than the site itself. Check that you can export them yourself, as a spreadsheet or CSV, without asking the developer each time.

Also ask where backups are stored, how often they run, and how long they're kept. A backup stored on the same server as the site doesn't help much if that server fails.

If you're on a subscription platform rather than a custom build, you're renting. That can be the right choice, but read the export terms before you commit. Teachers weighing this up should read ready-made subscription platforms vs a fully custom one.

Owning the data also means being responsible for it. Egypt, Saudi Arabia and the UAE all have personal data protection laws, and they apply to the phone numbers and names in your database.

Accounts: the quiet dependency

These are the ones nobody thinks about until the person who created them leaves:

  • Business email on your domain. The admin account should be yours.
  • Google Analytics and Search Console. You as owner, the agency as a user.
  • Google Business Profile. This is your Maps listing, and it's surprisingly hard to reclaim.
  • Payment gateway merchant account. It must be in your business's name, with settlements going to your bank. Never run customer payments through a developer's merchant account.
  • Social pages and ad accounts, including any tracking pixels installed on the site.
  • App store developer accounts, if you have a mobile app. Your app should be published under your own Google Play and Apple developer accounts.

Your handover checklist

Ask for these before you make the final payment:

  • Registrar login, with you listed as registrant
  • Domain expiry date noted and auto-renew on
  • Hosting or server login, or a written promise of a full backup on request
  • Complete source files and a recent database copy
  • Admin panel login with full permissions
  • Business email admin access
  • Owner access to Google Analytics, Search Console and Business Profile
  • Payment gateway account in your business name
  • A list of every third-party service the site uses, with who pays for each
  • A short written guide to the admin panel

Store all of it in a password manager, not in a WhatsApp chat.

Common ownership mistakes

  • Registering things with the developer's email. Even with good intentions, you now depend on their inbox.
  • Paying renewals through the agency with no visibility. Fine, as long as you can see the expiry dates yourself.
  • Assuming paying means owning. Payment and legal ownership are different things. The contract decides.
  • Letting an employee own the accounts. The marketing hire who set up your Facebook page and Analytics leaves, and takes the owner role with them. Company accounts belong on company emails.
  • One shared password for everything. When one account leaks, they all do.

Questions people ask

Is it normal for the agency to keep the hosting?

Yes, as long as you can get a full backup and move whenever you choose. The risk isn't managed hosting. It's hosting you can't leave.

Can I ask for the source code if I'm on a maintenance contract?

Yes. A maintenance contract pays for someone to look after the site. It shouldn't be a reason to withhold files you already own.

What's the difference between owning the code and having an admin panel?

The admin panel lets you edit content. The code is the site itself. With only a panel, another developer can't rebuild or move your site if something goes wrong.

My domain is registered in my developer's name. What should I do?

Ask politely, in writing, for it to be transferred to you, and pay any renewal fee due. Most developers agree. If they won't, get advice before the domain comes up for renewal.

Do I own a site built on a subscription platform?

You own your content and usually your data, but not the platform. You're renting the software, so check what you can export and what happens to your site if you stop paying.

Check it this week, not during a crisis

Take 30 minutes this week and go down the handover list. For each item, write down who holds it today. Anything that isn't in your name is worth fixing now, while everyone is calm and still answering their phone.

If you're starting a new project and want ownership handled properly from day one, book a meeting and we'll go through how it works with us, item by item.

Share this article
Keep reading

Close to what you just read

All the articles

Cost & planning 8 min read

How Much Does a Website Cost in Egypt in 2026?

Three quotes for the same website, three wildly different numbers. Here is what each price actually buys, and how to get a quote you can trust.

Read the article

Cost & planning 8 min read

How to Choose a Web Development Company: 10 Questions

Every portfolio looks good. These ten questions show who will actually build your site, who will own it, and what happens when something breaks.

Read the article

Cost & planning 8 min read

The Hidden Costs of a Cheap Website, and How to Spot Them

The 5,000 EGP website rarely stays a 5,000 EGP website. Here is where the real bill shows up, and the questions that expose it before you pay.

Read the article