Why your AI share link won't open for them (2026)

You built the thing. It works in the preview. You grabbed the share link your AI tool offered, sent it to a client — and the reply came back: "it's asking me to log in," or "the page is blank," or "this expired?"

The build is fine. The problem is the link — and specifically, who the link was designed for.

The link your AI tool made assumes the reader is you

Every prompt-to-app tool gives you a way to "share." But that share is built for the path of least resistance inside the tool — keep the reader on the platform, signed into the account that has access, with the session still warm. That's great while you're the one looking. The moment the audience is a client, a teammate in another company, or a friend on their phone, the assumptions break one by one.

It's worth seeing the failure tool by tool, because each one fails differently — and the fix is the same shape every time.

Lovable and v0 — the only "real" link is a public one. The in-editor preview is tied to your session and your account; the version you can actually hand out is a publish or a deploy, which puts the build on the open, indexable web. So your two options are "they can't open it" or "the whole internet can." For showing a draft to one person before it's ready, neither is right. (Share a Lovable app privately and share a v0 build without deploying are the in-between.)

Bolt — the preview dies with the session. A bolt.new preview link runs inside the StackBlitz environment that built it. Close the project, and the person you sent it to is looking at a blank page or an error. The link was never a stable address; it was a window into your live session, and the session closed. (A bolt.new link that stays is the export hosted on its own.)

Gemini Canvas — the org wall. If you're on a work or school Google account, public sharing is often switched off by an admin you'll never meet. The Canvas link works beautifully for you and for no one outside your organisation — and plenty of recipients don't have a Google account to begin with. (Share a Gemini Canvas as a link anyone can open routes around it.)

Claude and ChatGPT artifacts — the platform account. An artifact share link tends to bring the reader back onto the platform: an account prompt, a sign-in, the construction site instead of the finished room. For a polished hand-off, that's friction the recipient didn't ask for.

Different walls, one pattern underneath: the share link assumes the reader lives where you built the thing. Most of the time, they don't.

What "opens for anyone" actually requires

The fix isn't a better account setting. It's giving the build an address that doesn't depend on a login or a session at all.

That means three things, together:

• A self-contained export. Most of these tools can ship the build as a single .html file (CSS and JavaScript inlined) or a zipped folder. Once it's a file, it's no longer tied to the tool that made it.
• A link that isn't a platform login. The file gets its own URL — not a window into your session, not a door into a workspace. It runs on its own, so closing your tab changes nothing.
• No sign-in on their end. The recipient opens it in whatever browser they have, on a phone or a laptop, with nothing to install and no account to create. The link is unguessable and stays out of search, so "opens for anyone you send it to" doesn't mean "open to the public web."

That last distinction is the whole game: the link should open for the people you chose, and stay closed to everyone else — without making any of them log in.

The honest exception — when it really does need a backend

Worth being straight about scope. This pattern is for the self-contained build — the front end, the prototype, the page or tool that runs entirely in the visitor's browser. If your app signs users in, writes to a database, or runs server-side code, it isn't a file and it can't be one. That's a real deploy, and Vercel and Netlify are built for exactly that — they host the full app with its server side intact. Lovable, v0, Bolt, and Replit all publish to a live URL for the same reason.

The "host the export as a private link" pattern covers the step before that deploy — and the very common case of a build that never needs a backend at all. When the recipient just needs to open the thing and see it work, a private link is the lightest tool that does the job.

One link that opens for them

The recipient's experience is the test that matters. They click; it opens; it works; they didn't have to log into anything. Whatever you built it in — Lovable, v0, Bolt, Gemini, Claude — the move is the same: export the build, put it on a link that isn't tied to your account or your session, and send that. And if you want their reaction back, turn on Review and they can pin feedback to the exact spot on the page — still with no account to create.