Deploying a site on Vercel takes about a minute once the code sits on GitHub. The rest of going live takes half a day, and it happens elsewhere. The domain name, the records at your domain host, the plan choice and the region your code runs in make up the real list of things to settle.
This tutorial follows on from our account of building the Tandem website with Claude. That article covers how the site was designed and coded. This one explains only how to make it public, step by step, without assuming you are a developer.
Vercel is a hosting and deployment platform for websites and web applications. It reads your code on GitHub, builds it and serves it to visitors. You manage no server and you touch no command line.
What to have ready before you start
Three things are enough, and none of them calls for particular technical skill. Allow twenty minutes to gather them before you open anything.
- The site code on your machine. If you built it with a coding assistant, it already lives in a folder on your computer.
- A GitHub account. Free, created in two minutes, this is where the code will be stored and versioned.
- Your domain name, and above all the credentials for the account where you bought it. OVHcloud, Gandi, Namecheap or another, it hardly matters, but you need to be able to log in.
That last point blocks projects more often than the other two. Many companies bought their domain eight years ago through a supplier who has since moved on. Recovering access can take several days, so start there.
Step 1, send the code to GitHub
GitHub stores the code online and keeps the full version history. Every change is tracked and reversible, which matters the day an edit breaks a page.
If you work with a command line coding assistant, this step can be asked in plain English. « Create a repository and push the site code to it » is enough. The assistant asks for authentication once, then handles the rest. Our Claude Code guide for non-developers covers this mechanism if the terminal is still unfamiliar.
Step 2, import the repository and run the first deployment
Create your Vercel account by signing in with GitHub. The two accounts then talk to each other directly and you avoid a manual setup.
- In the dashboard, choose to create a project and select your repository.
- The platform recognises the technology on its own and fills in the build settings.
- Run the deployment. About sixty seconds later, the site answers on a vercel.app address.
That address is public and shareable straight away. I often use it to get a redesign approved before touching the real domain. I summarised this journey in six steps in my LinkedIn post on the Tandem website rebuild, and it really is the last one that concentrates the difficulties.
If the build fails, the log shows the offending line. Copy that message to your coding assistant, fix it locally, send the code again. The platform restarts the build on its own with every push.
Step 3, connect your domain name
This step happens in two places. You declare the domain on the Vercel side, in the project settings. Then you create two records at the registrar where you bought the domain, meaning OVHcloud, Gandi or an equivalent.
A DNS record is a line telling the internet which machine to send your address visitors to. You need two, one for the bare domain and one for the www version.
Here is the point almost every tutorial misses. They give one single network address to copy, the one that served everybody for years. The publisher's knowledge base now says something else. Recent projects receive a value drawn from a pool, and the documentation states that each project has its own CNAME. Copy what your own screen displays, verification expects that precise value.
The mistake that cuts company email
Vercel offers a second method, changing the nameservers. It looks simpler because it replaces the two records with a single setting. It is also the one that causes the most expensive outage.
Changing nameservers hands over management of your whole zone. Your email addresses depend on it, through records called MX. If you switch without copying them over first, company email stops dead, and nobody connects it to the website.
The publisher's documentation states the warning in plain words. Its troubleshooting table even lists the symptom as such, mail stopped arriving after a nameserver change. On a company domain, prefer the two records. They touch only web traffic and leave email intact.
The free plan is reserved for personal use
Here is the point most often left unsaid, including in my own content. The publisher's fair use policy restricts the free plan to non-commercial personal use. Any commercial usage requires a paid plan.
The definition is broader than it looks. The fair use guidelines describe as commercial any deployment serving the financial gain of anyone involved in its production. An employee or a consultant paid to write the code falls under that definition. They also cite advertising a product or a service for sale. A small company brochure site ticks both boxes, even with no online payment.
In my newsletter edition about the website rebuild, I wrote that both building blocks of going live were free. That holds for GitHub and for a personal project. For a company site, budget around twenty euros a month, publisher rate recorded in October 2026.
Two billing details deserve your attention. Prices are shown in dollars and before tax, so a French company's real invoice adds value added tax and a currency conversion. And the first-year free domain covers neither .fr nor .com, only a short list of technical extensions.
Where your site runs, and why the question matters
The static pages of your site are served from a global network, with more than 120 points of presence. For a French visitor, the page arrives from nearby. Nothing to set on that side.
Code running on the server side follows another rule. The regions documentation states that these functions run in Washington, in the United States, by default. A Paris region does exist, and a German one too. The default setting is therefore not the one most French companies expect.
| Region | Location | What it changes |
|---|---|---|
| iad1 | Washington, United States | The default setting, outside the European Union |
| cdg1 | Paris, France | Processing in France, lowest latency for your visitors |
| fra1 | Frankfurt, Germany | Processing inside the European Union, a common fallback |
The question becomes concrete as soon as a contact form passes through that code. Details entered by a visitor are personal data, and where they are processed has to be documented. Switching the region to Paris takes one line of configuration, and your coding assistant knows how to write it.
If hosting location weighs heavily in your organisation, our article on running AI locally covers the underlying question, hardware included. This tutorial stops at the setting worth knowing.
Every change goes back online on its own
Here is the real comfort of this setup, and the reason half a day of investment pays off quickly. Once the wiring is done, you never come back to it.
You ask your assistant for a change, you ask it to send the changes, and the new version builds then publishes in about thirty seconds. No handling, no file transfer, no admin interface to reopen.
One last setting is worth the detour. Each working branch gets its own preview address, separate from the public site. You get a new page reviewed without anyone else seeing it. I detailed the full journey in my newsletter edition on the website rebuild, from mockup to going live.
Putting your site online on Vercel, the order that avoids outages
Take the steps in this order and going live fits in half a day. Recover access to your domain name first, because it is the only point that can take days. Send the code to GitHub, deploy, check the site on the temporary address.
Then choose your plan according to the real use of the site, before connecting the domain. Create the two records with the values displayed in your project. Leave the nameservers alone if email addresses depend on the domain. Finally set the execution region if your site handles visitor data.
This mechanism also applies to an internal business tool, not only to a brochure site. Our custom internal tools deploy in exactly the same way. And if you want to hold the chain yourself, from mockup to going live, our Claude Code training covers that journey end to end.
