How do you show a Cursor project to a non-technical client?

A repository or a localhost link means nothing to a client. How to turn a Cursor project into a working demo with a tour, on a link of their own.

On this page

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

Send the running app, not the repository. A client cannot open your localhost, and code tells them nothing. Put the app live on mock data, add a short tour in plain words, and give them their own link. Cursor’s agent can run Roomi’s commands for you, and nothing is published until you approve the rehearsal.

This guide is for someone who builds in an editor and sells to people who never open one. It covers what Cursor can publish, which way of showing the work suits a client, and how the agent puts it in a room. Then how to write a tour a non-technical client follows. Share what you built in Cursor is the short version.

Because neither shows the client anything. A localhost address only opens on your own machine. A repository is code, and code says how it works, not what it does for them. A recording goes out of date with your next commit, and they cannot click anything in it. A client needs the running app, explained in their words.

What a client is really asking is “what does this do for me?” Your repository answers a different question, and your commit messages answer a third. The job is translation: the working app on a link they can open, with a few sentences beside each screen saying why it matters to them.

What can Cursor publish?

Cursor can publish to Vercel. A cloud agent links your repository to a Vercel project, deploys it and replies with the address. Origin, Cursor’s code hosting, gives pull requests their own Vercel previews. Who can open those addresses is then Vercel’s question, answered by your Vercel plan and its protection settings.

A Cursor cloud agent can publish a repository to Vercel and reply with its address, and later commits to its default branch go live on their own. It needs a Vercel account, and a Cursor team needs a Vercel plan above Hobby. Cursor’s git forge, Origin, connects to Vercel: pushes can trigger deploys, and pull requests can get preview environments.

Once it is on Vercel, the ways in are Vercel’s:

  • A public address, for anyone who has it. Vercel’s Hobby plan is free, and Vercel says it is for personal, non-commercial use.
  • A shareable link. A Vercel shareable link lets anyone who has it open a protected deployment, through a query string in its address. Shareable links are on every plan.
  • An invitation. Vercel recommends inviting outside viewers to a deployment by email, and you can revoke each person’s access. On Hobby you can have one collaborator at a time.

What you learn afterwards is Vercel’s too. 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.

One thing to notice for client work: on a published address, later commits go live on their own. A client who opens it sees whatever you pushed last, half-finished work included. A room changes only when you deploy to it. Vercel shareable link or a room compares the two in detail.

Which way of showing it fits a client?

The one where they can use it without you, and you learn what they did. A screen share teaches you a lot, but only during the call. A recording cannot be clicked. A Vercel address counts visitors without names. A room shows the app with a tour, on their own link, and tells you what they did.

Way What the client needs What they get What you learn
A screen share A call in their diary You driving What they say on the call
A Loom recording A link A video they cannot click Their name only if they watch signed in to Loom
Cursor’s Publish, to Vercel The address The app, as last committed Visitors in total, with no names
A Vercel preview for a pull request Access set up in Vercel A build for review Not described
A room on Roomi (ours) Their own link, and a browser The app, a guided tour and a way to answer Each person’s visits, time on each screen, tour and answers

Ranked for one job: a non-technical client trying the work alone, and you knowing whether they did.

  1. A room on Roomi — the running app, explained step by step, on a link named for them. We make it, so weigh that.
  2. A screen share — the best conversation, while it lasts. They cannot try it alone, and you learn nothing afterwards.
  3. Cursor’s Publish, to Vercel — the real app at a real address, from your agent. It shows the latest commit and counts visitors without names.
  4. A Loom recording — quick to make. Loom names a viewer only when they watch while logged in to Loom. Anyone else shows as an anonymous view.
  5. A pull request preview — made for reviewing code with your team, not for a client.

Put a Cursor project in a room

The agent does the technical part, and you make the two decisions that matter: what goes live, and who gets a link. The deploy only rehearses unless you add --commit, so the agent can run it safely.

  1. Install and sign in yourself. Run npm install -g @getroomi/cli, then roomi login, which opens your browser for you to approve. The agent never signs in for you. Install the CLI has the details.
  2. Ask the agent to run roomi init. It writes pitch.json, and PITCH.md, a guide to the rules: mock data only, no secrets, and nothing published without your yes. It adds a line to AGENTS.md pointing Cursor’s agent at it.
  3. Make it a demo. Ask the agent to swap any real database or AI calls for sample data. An app with its own server becomes a container demo, built with Docker on your machine, running on Node 24 with no internet.
  4. Look at it on your machine. With your dev server running, roomi dev shows the real room around it, tour and all. Nothing in it is recorded or sent. Preview locally covers it.
  5. Let the agent rehearse. Ask it to run roomi deploy and show you the output. It builds the app, scans for secrets, checks every step of the tour, and says what would go live.
  6. Say yes. The agent runs roomi deploy --commit. To look at the build on the platform first, it can send it as a preview deploy, which only you and your team see until you make it live.
  7. Make the link. Ask the agent to run roomi link "Priya Shah" --expires 14, and send the address yourself.

To start it all, say to Cursor’s agent: “Deploy this to Roomi. Read PITCH.md, rehearse, and show me the rehearsal before you publish anything.” Build with your AI agent covers what roomi init leaves for it.

When you send the link, say who you are and how to reach you, and that the room records what they do there and shows it to you. Roomi’s terms ask every publisher to say so.

How do you write the tour for someone non-technical?

In their words, not the build’s. Three to six steps, one idea each, in the order you would pitch it. Each step opens the screen that makes the point and says what to notice, as a benefit to them. Leave out how it was built. If a step needs a technical word to make sense, it is the wrong step.

What you built What the step says
Sign-in by magic link “Your team signs in from an email. Nobody has a password to forget.”
Live updates over a socket “When a colleague changes an order, you see it here at once.”
Role-based permissions “Managers approve; everyone else can only suggest.”
A CSV import with validation “Drop in last month’s spreadsheet. Anything that doesn’t fit is flagged before it’s saved.”

Cursor’s agent can draft the steps from the app, and you rewrite them in your client’s words. Each step stands on its own, because a viewer can start anywhere, or leave the tour to explore freely. Writing the tour has every rule. The demo tour script template gives you the steps to fill in.

What will you learn after you send it?

Person by person, on Pro: when they opened their link, how long they spent on each screen and how far through the tour they got. Also what they commented, and their answer to what happens next. If they forward it, the next person is asked who they are. Each link’s card moves through the pipeline as they go.

The stages are sent, opened, engaged, said yes, later and not now, and each comes from what the person did, never a score. Who to call first, at the top of the app, names the one person most worth a call today, with the evidence in words. What the room records lists every measure, and tech sales shows the same loop with a sales team.

Questions people ask

Can Cursor’s agent deploy to Roomi for me?

It can rehearse, with roomi deploy, and show you exactly what would go live. It publishes only when you say yes and it runs roomi deploy --commit. The guide roomi init leaves in your repository tells it to wait for that yes.

Does my client need Cursor or GitHub?

No. Your client opens a link in a browser and the room opens, with nothing to sign up for or install. They never see your repository, your editor or your code.

Do I need Docker?

Only for an app with a server of its own. That runs as a container demo, on Pro and above, and Docker builds it on your machine. An app that runs in the browser alone deploys as static files, without Docker.

Yes. Ask it to run roomi link with your client’s name, and it gives you the address. You send it yourself, by email or however you usually reach them: Roomi sends nothing.

Can I see the room before the client does?

Yes, two ways. roomi dev shows the real room around your running dev server, on your own machine, and records nothing. A preview deploy puts a build on the platform for you and your team only, until you make it live.

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.

Let the agent deploy it. You say when.

Start free, and give each client a link of their own on Pro.

Get started freeSee pricing