It usually goes like this. Someone in marketing spends an evening with Claude or ChatGPT and builds a small tool: a page that tracks the trade fairs of the year, with the budget and the contacts. It works. It even looks good. The next morning they post in the team chat:
Léa: I built a great tool to track our fairs, want to see?
Marc: Yes!
Léa: Look:
http://localhost:3000
And nothing opens. Not on the colleague’s computer, not on a phone, not anywhere. The tool exists, but only for one person.
This article explains why, in plain words, and what it takes to turn “it works on my computer” into an address anyone can open.
What “localhost” means
localhost is the name every computer gives to itself. When your AI says “your site is running at localhost:3000”, it means: a small program on this computer is showing the site, and only this computer can ask for it. The number after the colon (3000, 5173, 8080) is just a door number on the same machine.
So when you send localhost:3000 to a colleague, their browser asks their own computer for the site. Their computer has never heard of it. Hence the “This site can’t be reached”.
It is not a bug and you did nothing wrong. AI tools build on your computer because it is the fastest way to try things. Putting the result online is a separate job, and it is the job nobody explains.
Why the AI did not just put it online
Most AI assistants can write a whole site in minutes. They usually stop short of publishing it, for good reasons:
- Publishing needs somewhere to live. A site online runs on a server that stays on day and night. Your AI does not own one for you.
- It needs an address. Something like
fairs.your-company.com, which means a domain, its settings, and a security certificate (the padlock). - It needs to keep working. When you close your laptop,
localhostdisappears. An online site must not. - Someone should decide. Publishing is visible to the world. Letting an AI push things online on its own, with nobody checking, is not something most companies want.
Each of these is solvable. The trouble is that, separately, they turn a fun evening into a technical project.
What “online for real” takes
Here is the checklist, in the order you will meet it.
1. A real address
You need an address that works from any computer and any phone. Two common choices:
| Option | Looks like | Good for |
|---|---|---|
| A free address from a hosting service | fairs-tool.some-host.app |
Trying, sharing with a few colleagues |
| Your company’s domain | fairs.your-company.com |
Anything customers, candidates or partners see |
A subdomain of your company’s domain inspires trust and keeps the link stable for years. Setting it up means adding one or two records in the place where your domain is managed (often the IT team or the agency that made the main site). It takes minutes once you know which records.
2. A security certificate
Browsers warn visitors about sites without the padlock (https). The certificate must be created, then renewed regularly. Good hosting does this for you, silently. If you ever have to think about it, something is wrong.
3. Forms that reach someone
Most useful tools have a form: a contact request, an application, a waiting list. On your computer, the AI may have stored submissions in a file, or nowhere. Online, each submission must:
- be kept somewhere safe,
- notify the right person (an email to Julie in HR),
- and often reach a tool the team already uses: a CRM, a recruiting tool, a spreadsheet.
Forms also attract robots. Without protection, a public form fills with spam within days. Limits per sender and a hidden trap for robots solve most of it.
4. Texts the team can change
The day after launch, someone will want to fix a typo, change a price or add a job offer. If every change requires opening the AI conversation again, the tool will slowly go out of date. A good setup gives the team a simple editor for the texts and images, with a clear button to update the site when they are ready.
5. Data that stays
If your tool keeps information (the fairs, the contacts, the bookings), that information must live in a real database, backed up, separate for tests and for real use. A list kept in the browser of the person who built it is gone the day they clear their history.
6. Someone approving changes
This one is easy to forget. When the AI changes the site, who checks before it goes live? The healthy pattern is:
- the AI makes a preview: a private copy with the change, at its own address;
- a person looks at it, on a computer and on a phone;
- that person approves, and only then is it online;
- if something is wrong anyway, the previous version comes back in one click.
This is how you keep the speed of AI without waking up to a broken careers page.
7. Knowing it works
Finally: is anyone visiting? Are forms arriving? Is anything broken? A simple count of visitors, and a way to see errors, is enough for most small tools.
The usual ways people solve it
There are three common paths, each with its trade-offs.
Ask a developer. It works, if you have one available. It also means a queue, and your small tool competes with the main product.
Stitch services together. A host for the pages, a form service, a database service, a payment service, a domain registrar. Each is fine. Together they are five accounts, five bills, and settings your AI has to configure without breaking.
Use a platform made for it. One place that hosts what your AI builds and provides the pieces (forms, data, accounts, domains, approvals) already connected. This is the gap Leaf was made for.
How Leaf handles it
Leaf connects to the AI you already use (Claude, ChatGPT, Mistral, Cursor and others). You describe what you need in your words; the AI builds it directly on Leaf, not on your computer. So there is never a localhost link to send:
- every change becomes a private preview with its own address that you can share with your team;
- a person approves before anything goes online (that is the default for every site);
- the site lives on your domain, with the certificate handled;
- forms are kept, filtered for spam, sent by email, and can reach your CRM or HR tool;
- your team edits texts and images in an editor made for the site, then clicks “Update the site”;
- every version is kept, so going back takes a click.
Your AI also checks its own work before showing you: it takes screenshots on a phone and a computer, sends the forms in test mode and reads the errors.
In short
localhost:3000 is the address of a draft on one computer. To make it a real link you need an address, a padlock, forms that reach someone, texts the team can change, data that stays, and a person approving what goes online. None of it is hard on its own; together it is a lot to ask of an evening project.
The good news: the hard part, having the idea and building it, is already done. What is left can be handled for you.
Aussi en français : localhost:3000 n’est pas un lien