The site is delivered, everything works, the developer has moved on to another project. A year later a renewal notice arrives, and it turns out the registrar account is in the contractor’s name, hosting is paid from their card, and only they know the panel password. The site is yours on paper, but you cannot run it.
This is not about distrust. People change jobs, lose phones, and forget passwords. Below is what should be in your name before launch, and how to give a developer access without handing over every key.
The domain
The domain matters more than anything else. Hosting can be moved in an evening and code can be rebuilt, but the address your clients and search engines know has no replacement. So the domain holder at the registrar should be you or your company, not the studio and not a friend who codes.
- The registrar account uses an email you actually read
- The domain record lists you or your company
- You know the renewal date and who pays for it
- Auto-renewal is on, or there is a reminder in your calendar
If the developer needs to change DNS records, that is done through DNS management access or by pointing the domain at their name servers. It does not require the whole registrar account.
Hosting or a VPS
The hosting account is opened in your name and billed to your card or company account. The developer gets separate access: their own panel user, FTP, or SSH with their own key. They should not know your main password, and they do not need it to do the work.
A VPS works the same way. If the server runs a panel such as aaPanel, you should have the panel address, a login, and a clear idea of where root access to the server itself is kept. A server only one person knows becomes a problem on the day that person does not answer.
Code and the repository
The code of a site or a bot should live somewhere besides the server. Usually that is a repository on GitHub or a similar service. It is best when the repository sits in your account or organization and the developer is added as a collaborator. If they keep the code in their own account, agree that it is transferred to you at delivery, and check that the transfer happened.
An archive sent in a messenger is better than nothing. But six months later nobody can say whether it matches what runs on the server.
Email, forms, and bots
Requests from the site go to email or to Telegram. The mailbox the site sends from should be on your domain or in your account. You create the chat where requests land and add the bot to it, not the other way round.
A Telegram bot belongs to the account that created it in BotFather. It is better if that is your account or the company’s. Treat the bot token like a password. If it ends up in the wrong place, you revoke it in BotFather and the old token stops working.
Analytics and search
Google Search Console, Google Analytics, Yandex Metrica, and Yandex Webmaster are connected to your account. The developer is added as a user with the rights they need. If the counter or the site verification sits in someone else’s account, the visit and query history leaves with that account.
The access list
One document that lists everything related to the site. Not passwords, but places: where each thing lives, whose name it is in, who has access, and when it renews.
- Domain: registrar, holder, renewal date
- Hosting or VPS: provider, plan, who pays
- Panel and server: address, who has been given access
- Repository: where it is, who the collaborators are
- The mailbox for forms and the chat for requests
- Bot: the creator account and where the token is kept
- Analytics and webmaster tools: whose account, who is added
Keep the passwords themselves in a password manager, not in a chat. A year later, a contractor thread turns into a search through a hundred messages.
When the developer changes
If you part ways with a developer, walk the same list backwards. Remove their user from the hosting panel and the repository, take their SSH key off the server, change the passwords they knew, and revoke the bot token if they had it. This is routine hygiene, not an accusation.
What to check at delivery
- You logged in to the registrar yourself and see the domain there
- You logged in to the hosting account or the server panel yourself
- The repository opens under your account
- A test request from the site arrived where it will be read
- The bot replies, and you know which account created it
- The access list is filled in and kept by you
Until every line is checked with your own hands, the project is only half delivered. It takes an hour and saves weeks when something breaks or you need a new contractor.
Why a quote has lines for the domain and hosting is covered in the note on what a site costs. How a bot with a token and a staff chat is built is in the note on a Telegram order bot. To launch a project where everything stays yours, use the contact form.