What is the best way to share an app you built with AI with a client?

Built it with Claude, Lovable, v0, Bolt or Cursor? Five ways to put it in front of a client, ranked, with what each one tells you afterwards.

On this page

By Kaz Kato · Published 12 October 2026 · Updated 12 October 2026

The best way to share an app you built with AI is a private link for each client, with a guided tour and a record of what they did. Publishing from the builder is fine for a quick look. For a sale, you need to know who opened it, what held them and when to call.

This guide ranks five ways to put an AI-built app in front of a client, from a room to a screen share. It says what each one tells you afterwards, and how to get your app into a room from wherever you built it. Deploying from Claude and static demos have the detail.

Five ways to share an AI-built app, compared

Way Can the client click through it? What the client needs Private to one person? What you learn afterwards
A room on Roomi Yes, with a guided tour A browser: no account, nothing to install Yes: a link each, which can expire or be switched off Each person’s visits, time on each screen, how far they got, comments and answers
A screen share on a call No: you drive A time in their diary Yes, for the length of the call What they say on the call
Publishing from Lovable, Bolt or v0 Yes Nothing for a public address; a sign-in for some private ones On some plans, by invitation Traffic in total, not people
A Loom recording No: they watch A browser, and a Loom sign-in if you share it with specific people Yes, if they sign in to Loom Who watched, if they were signed in to Loom
Sharing from Claude Yes From Claude’s apps, a Claude account, signed in; from a Claude Code public link, a browser From Claude’s apps, by email invitation No record of who opened it is described

Ranked for one job: showing a client the working app, and knowing when to follow up.

  1. Roomi — the only one with all three: a link for each client, a guided tour and a record of what each did. Your client signs up to nothing.
  2. A screen share — you see every reaction and answer as you go. But the client cannot try it alone, and you learn nothing once the call ends.
  3. Publishing from Lovable, Bolt or v0 — the real app at a real address, in a click. Its analytics count traffic, not the person you sent it to.
  4. A Loom recording — quick to make and easy to watch. Nobody can click anything in it, and viewers who are not signed in are anonymous.
  5. Sharing from Claude — fine for a colleague who uses Claude. From Claude’s apps, a client has to make a Claude account first. Claude Code’s public link needs none, but its page describes no record of who opened it.

What does each tell you after you send it?

Most tell you little. Builder hosting counts traffic in total, not people. A recording names only viewers signed in to its service. A call tells you everything, but only while you are on it. A room on a paid plan tells you what each person did: when they came, what held them and what they said.

Publishing from the builder

Lovable’s analytics measures overall traffic, not individual people, and does not follow a visitor from one visit to the next. On a paid plan, Bolt’s hosting analytics show unique visitors, page views, top pages and traffic sources for a published site. They include visits from crawlers and bots.

v0 publishes a project to Vercel. Who can open the deployed app depends on your Vercel plan and its deployment protection settings. Vercel’s Web Analytics tells visitors apart by a hash that resets every day, without cookies. It reports pages, referrers, countries, operating systems and browsers across all visitors.

That is what a launch needs. A sale needs something else: none of it says whether the one person you sent it to has opened it.

A recording

Loom names a viewer only when they watch while logged in to a Loom account. Anyone else shows as “Anonymous”, with no way to see who they were. A Loom video can be shared with specific people by email, and each must be logged in to Loom with that address to watch it. A recording also goes out of date with your next change, and your client cannot try anything in it.

Sharing from Claude

Anyone opening an artifact shared from Claude’s apps, rather than published by Claude Code, needs a Claude account and must be signed in. The one exception is an older artifact published from a chat, which opens without one. Claude’s help page on sharing artifacts describes no way to see who has opened one.

Claude Code can publish an artifact to a public link that anyone can open, with no claude.ai sign-in. On Team and Enterprise plans, public sharing is off until an owner turns it on. Claude Code’s artifacts page describes no record of who opened an artifact, no expiry date and no guided tour. For anyone outside your organisation, it describes a public link, not one for a named person. People who reach a Claude Code artifact only by its public link do not see its comments, and cannot add any.

A room

On Pro and above, Roomi records every visit, click and minute, person by person. You see when each client opened their link, how far through the tour they got, which screen held them and what they said. You also see who they passed it to, and their answer to what happens next.

At the top of the app, one sentence says who to call first, with the evidence: “Call Sarah today. Seen today, back on Pricing, shared it with someone new.” Roomi emails you when a client comes back for another look. Ask your own Claude to draft the follow-up: Roomi hands it exactly what that client did, and nothing is sent until you send it. On Free, you see total views. What the room records lists every measure.

What should a client-facing share have?

Four things. A link of their own, which you can switch off. Mock data, never their real records or yours. A guided tour, so the app explains itself when you are not there. And one easy next step, such as booking a meeting, so a good visit turns into a conversation.

  • Their own link. On Roomi, each link carries the client’s name, can expire on a date you choose, and can be revoked at once. A closed link answers “Not found” and says nothing about you. If they forward it, the next person is asked who they are, so you see everyone involved. Sharing a private link covers every option.
  • Mock data. Every room tells its viewers the demo runs on mock data. The deploy stops on anything that looks like a live key. Each demo runs on getroomi.app, a domain kept apart from yours.
  • A tour. A few steps, each opening the screen that makes the case and saying what to notice. Claude drafts it with you when it deploys, or you write it yourself.
  • A next step. Book a meeting, yes, get back to me, bring in a colleague, ask a question, or not for me. A meeting books in the room from your weekly hours, or opens your own booking page.

How do you get an AI-built app into a room?

It depends where you built it. From a Claude chat, add the Roomi connector and say “deploy it to roomi”. From a repository, in Claude Code, Cursor or any agent with a terminal, the Roomi CLI deploys it. Either way, you see a rehearsal first, and nothing goes live until you say yes.

Where you built it How it reaches a room Plan
A Claude chat The connector, from the same chat: Claude writes the files a browser runs Any
Lovable, v0 or Bolt, with the code on your machine The CLI, from the project’s folder Any, for a static build
Cursor, Claude Code or your own repository The CLI, or the Roomi plugin in Claude Code Any, for a static build
An app with its own server A container demo, from the CLI Pro and above

roomi init recognises a Vite app, a Next.js static export and plain HTML. Anything that needs a server at request time runs as a container demo instead: container demos covers it. Since 13 May 2026, new Lovable projects are rendered on a server, built on TanStack Start. Earlier ones were single-page apps deployed as static files. On Roomi, a new Lovable project is a container demo, on Pro and above. The guides for Lovable, Bolt, v0 and Replit go through each builder step by step.

If your app talks to a live database or a paid service, swap it for sample data before you deploy. A demo runs on mock data, and a client should never see real records. Swapping real data for mock data shows how.

What should you check before you send it?

Three checks. Open the room in a browser you have never signed in from, so you see what the client sees. Take the tour yourself, and make sure each step opens the screen it talks about. And make sure nothing real is in it: no live keys, no client’s records, no one else’s name.

The deploy helps with the last two. It stops on anything that looks like a live key, and its rehearsal checks that every step of the tour opens a page the build has. The checklist for an app built with AI has the rest.

When you send the link, tell your client who you are and how to reach you. Say that Roomi records what they do in the room, and shows it to you. The terms ask every publisher to say so. Then watch for the first visit.

Questions people ask

Can a client open a Lovable app without an account?

On Lovable’s Free and Pro plans, a published app is open to anyone with its address by default; “Invite only” limits it to people you add, who must log in. A room on Roomi needs no account at all.

Anyone who has a public address can open it, and so can anyone they send it to. For client work, a link for each person that you can switch off, on mock data, is safer.

Can I see if a client opened it?

Not by person, from the builders’ own hosting: their analytics count traffic. On the paid plans of Roomi, you see each person’s visits, how far they got and what they said.

Does the app need rebuilding first?

Usually not. A static build, such as a Vite app or a Next.js static export, deploys as it is. An app with its own server runs as a container demo, and a live backend is swapped for sample data.

What does it cost?

You can start on Free, with a draft only you open or a public listing on the community. A private link for each client comes with Pro, at £4 a month or £40 a year, before VAT.

Sources

About the author

Kaz Kato, Co-founder & CTO, Roomi. Kaz co-founded Roomi with Tesh, whom he has built with since 2017: two startups that failed, one venture studio that didn’t, and an exit.

Send the app, and see who opened it.

Start free, and deploy from wherever you built it. A private link for each client comes with Pro.

Get started freeSee pricing