Direct answer
Create the accounts in your name first, then invite the vendor. If your code lives on GitHub and your application is hosted on Vercel, the business should own both from day one: you create a GitHub organisation and a Vercel team under your own login, with your business email and two-factor sign-in, and then give the vendor the access they need to work. The alternative, where the vendor builds under their own accounts and transfers everything at the end, works, but it puts control in the wrong hands during the project and makes the final transfer a step where things go wrong.
This page covers GitHub and Vercel only, since they are the ones people most often ask about. Other hosting and code platforms follow the same principle, but their specific screens and options differ and are not covered here. It also describes general practice, not a promise about how any vendor works; the details of your own project should be agreed in writing. For the broader question of what you should end up owning, see who owns the code and accounts after a custom build.
Why ownership matters
Code and hosting are how the business runs. If the account that holds them belongs to someone else, you depend on their goodwill, their continued availability and their account security. A vendor leaving, a freelancer becoming unreachable or an account being locked can all leave you unable to change or even see your own software.
Owning the accounts from the start also gives you a clear view of what is happening: you can see the history of changes, when deployments happen and what settings are in use, without asking anyone.
Organisation versus personal account
On GitHub, set up an organisation rather than putting the code in a personal account. An organisation belongs to the business, can have several owners, and survives people leaving. A personal account belongs to an individual, and access to it disappears with them. Vercel offers a team structure for the same reason.
Use a role or business email address that more than one trusted person can reach, not one person's private inbox. Make sure at least two people hold owner-level access, so that an absence does not lock the business out. Turn on two-factor sign-in for every owner and keep recovery methods under the business's control.
- GitHub organisation created by the business, with a business email
- Vercel team created under the business's own login
- At least two owners on each, with two-factor sign-in enabled
- Recovery options held by the business, not the vendor
Vendor roles
Give the vendor the least access that lets them do the job. On both platforms, roles range from read-only to full administrator. Developers typically need to write code and see deployments, but not to manage billing, delete the organisation or invite others.
Invite each vendor person individually by name, not through a shared login. Shared logins hide who did what and are hard to revoke cleanly. Check the current role descriptions on each platform, as their names and permissions can change, and write down who has which role and why. The related guide on API credentials and service account setup applies the same least-privilege thinking to integrations.
Billing
Decide who pays for what, and put the payment method on the business's account. Check which plan the project actually needs, since some team features on either platform depend on the plan, and confirm the current terms on the provider's own pricing page rather than relying on a vendor's summary.
Agree how hosting and usage costs are treated: whether they are paid directly by you, or passed through by the vendor with a statement. Paying directly, from your own account, keeps the arrangement transparent and makes later changes simpler. Set someone on your side to watch the invoices.
Environment variables
Environment variables hold the settings and secrets an application needs, such as the connection to its database or the keys for services it uses. On Vercel they are set per project and can differ between production and preview deployments.
Keep a written list of which variables exist, what each one is for and which are secret, without recording the values in the list. Secret values should be entered directly into the platform, never sent by email or chat, and never committed to the repository. Treat anything that has been shared widely as compromised and replace it at handover.
Domains
The domain name should be registered in the business's name, with the business controlling the registrar login. Connecting the domain to Vercel is then a matter of adding it to the project and making the DNS changes the platform asks for. Do this from the accounts you own, so the connection is under your control.
Note who manages DNS, where it is hosted, and when the domain registration and certificates renew. Missed renewals are a common and entirely avoidable cause of a site going offline.
Protected branches
On GitHub, protect the branch that feeds production. Branch protection can require changes to go through a review before they are merged, prevent direct pushes and stop the branch being deleted. This gives you a record of what went live and a chance to catch a mistake.
Decide who reviews and approves changes to production, and whether the business requires a named person to approve. Connecting the protected branch to the production deployment on Vercel, and other branches to preview deployments, keeps the path from a change to a live site clear. The release and rollback process describes how those changes should be handled.
Removing vendor access at the end
When the engagement ends, or changes character, review and remove access deliberately. List everyone from the vendor with access on each platform, and remove those who no longer need it. Where the vendor continues to help with maintenance, keep the minimum access and write down why.
Then rotate anything that was shared: secrets in environment variables, tokens issued to vendor accounts and any keys that passed through their hands. Check that you can deploy and change settings yourself with the vendor removed. The wider list of what to confirm at the end is in the software handover checklist.
Where LATYNEX fits
LATYNEX sets up development infrastructure remotely, in English, with scope and price agreed in writing before work starts, and works in accounts the client owns. Nothing on this page implies any partner or reseller relationship with GitHub or Vercel. For what an infrastructure setup can include, see development infrastructure setup.
Questions
Should the vendor create the accounts for us?+
It is safer if you create them yourself, under a business email with two-factor sign-in, and then invite the vendor. That way ownership never has to be transferred.
Does the vendor need to be an owner?+
Usually not. Give the least access that lets them do the work, and keep owner rights with the business.
What if the code is already in the vendor's account?+
Ask for it to be moved into an organisation you control, with the history intact, and confirm you can deploy from your own accounts before releasing the vendor's access.
Who should pay for hosting?+
Paying directly from a business account is the most transparent arrangement. Whatever you agree, put it in writing and check the provider's current pricing yourself.
Does this apply to other hosting platforms?+
The principles do: own the accounts, give least privilege, keep secrets out of code, remove access at the end. The specifics differ by platform and are not covered here.