Introduction

Roomi puts a working demo in front of a prospect instead of a slide deck. You deploy the demo you built, on mock data, and it runs in a room of its own: the live demo, a guided tour of it, and your pages beside it. Each viewer gets their own link. You see who looked at what, and read what they said back. These docs cover all of it, from both sides: building and deploying a demo, and sending it and following it up.

The quickest way in is Claude. Add the Roomi connector to Claude, say "deploy it to roomi" in a chat, and Claude does the rest, asking you before anything goes live. The Quickstart starts there.

What it is

A publisher has a working demo: several apps over one mock API, or a single app built with Vite. Until now the ways to show it to a prospect were a shared password or a screen share. Roomi deploys it and wraps it in a room:

• The demo, live. A viewer uses the real thing, framed as the device each app is for: a phone, a tablet, a laptop, a wall screen. A demo with a server gets a fresh copy of its own for every viewer link, so nobody breaks it for anyone else.
• The story. A guided tour you write, step by step, that tells the demo when you are not in the room, and your pages beside it: the narrative, a briefing, an architecture document.
• A way to answer. Viewers comment on the screen in front of them, and choose what happens next: book a meeting, say yes, ask a question, bring in a colleague, or say no and why.
• What happened. Each viewer's visits in order, time per app and page, how far they took the tour, and where every link stands in your pipeline.

Every demo runs on mock data, and every room says so. The platform around it is not mock: viewers' names, what they did and what they wrote are real, and are treated that way.

Who it is for

• Publishers: developers, agencies and founders who have built a demo, often with an AI coding agent, and want it live and in front of prospects without building a sharing and tracking system around it.
• Viewers: the prospects. They need nothing but the link: no account, no install.

How the pieces fit

Piece	Where	What it does
The connector	The Claude app and claude.ai	The platform's operations as tools, for Claude in a chat, with nothing to install: deploying a static demo, links, activity, feedback and listing on the Community. When a demo needs the CLI, it says so, and Claude offers to install it
The Claude Code plugin	Claude Code	Skills that turn "deploy it to roomi" into a rehearsed deploy through the CLI that publishes only on your yes, and then offer to list it on the Community
pitch, the CLI	Your terminal, in the demo's folder	Describes the demo in pitch.json, checks it, rehearses the deploy on your machine, publishes on --commit, makes links, manages pages and lists the project on the Community. For a container demo, a build bigger than a chat carries, and scripts
pitch.json	The root of the demo	Says what the build is: its apps and their devices, its tour, its controls and its pages. The room is drawn from it
The platform	api.getroomi.com	Holds projects, builds, links and everything viewers did, scoped to your workspace
The room	<project>.getroomi.app	What a viewer opens. The demo itself is served from a separate origin, <project>--demo.getroomi.app
The app	app.getroomi.com	Where you work as a publisher: builds, links, activity, analytics, the pipeline, feedback, your brand and your plan

Two ways to deploy

Most people start with the connector, from a chat. The CLI is there for what a chat cannot carry. Either way, nothing is published until you have seen a rehearsal and said yes.

From a chat, with the connector

1. Add Roomi to Claude as a custom connector, https://mcp.getroomi.com/mcp, and allow it on your workspace.
2. Say "deploy it to roomi". Claude reads the build contract with deploy_guide, writes the demo's files and its tour, and checks them with check_bundle.
3. deploy_static rehearses, and Claude shows you what would go live. Nothing has been sent.
4. On your yes, deploy_static with commit: true publishes it, and the build goes live in the room.
5. Claude makes a link for each viewer with create_link, or on Free lists the room on the community, and later tells you who looked and what they said.

From a terminal, with the CLI

1. pitch init reads your repository and writes pitch.json.
2. pitch validate checks it against the contract.
3. pitch deploy rehearses: it scans for secrets, builds the demo, runs a container demo on the platform's own runner on your machine, runs each step of the tour on that copy, and shows what would go live. Nothing leaves your machine.
4. pitch deploy --commit publishes exactly what the rehearsal checked, and the build goes live in the room.
5. You make a link for each viewer, from the CLI, the app or Claude, and send it yourself.
6. You watch what they do, and answer what they say, in the app.

Which to use

	The connector	The CLI
Where	claude.ai and the Claude app, in a chat	Your terminal, or Claude Code with the plugin
Deploys	A static demo held in the chat: at most 200 files and 3 MB in all	A static build of at most 5,000 files, 32 MB per file and 256 MiB unpacked, or a container demo
Checks before publishing	check_bundle: every app and tour step has its page, no hidden files, no common shapes of live credential	It builds the demo, scans it with gitleaks, and runs a container demo and every step of its tour on your machine
To install	Nothing: it is added in Claude's settings	npm install -g @pitch-product/cli, then pitch login, with Node 24
Links, activity, feedback, the community	Yes	Yes

Start with the connector. When a demo has a server, is bigger than a chat carries, or lives in a repository you work on with Claude Code, the connector says so: in Claude Code, Claude offers to install the CLI for you, and in a chat it gives you the two commands. Deploying from Claude has the detail.

Two kinds of demo

	Static	Container
What it is	A built folder of HTML, CSS and JavaScript	A server: an API and the apps it serves
Built from	Your build script, into an output folder	Your Dockerfile
Runs as	Files, served to the viewer's browser	A copy of its own for each viewer link
Demo controls and a tour that changes the demo	No	Yes
Needs Docker to deploy	No	Yes
Deployed from a chat	Yes, up to 200 files and 3 MB, through the connector	No: from your machine, with the CLI

Concepts explains every term these docs use.

Plans

Roomi is in early access, and every workspace starts on Free. Free has five projects and runs static demos; each is either an unlisted draft that only your workspace can open, or listed publicly on the community. Private links for each viewer, live app demos, analytics in full, the pipeline and your own branding are the paid plans', which are defined but cannot be bought yet. Plans and limits has the details.

Where to start

Getting started

• Quickstart: Columbus, a static demo, from a new account to a public room on the community, starting in a chat with Claude.
• Deploying from Claude: the connector for Claude in a chat, and the Claude Code plugin.
• Install the CLI: npx @pitch-product/cli, for a container demo, a bigger build, a terminal or Claude Code, and signing it in.
• Your first container demo: a demo with a server, a copy for every viewer.
• Build with your AI agent: what pitch init leaves for the agent building the demo.
• Sharing a private link: one link per viewer.
• Listing on the Community: a public address for a demo, from Claude, the CLI or the app.

Building the demo

• Writing the tour, Container demos, Static demos and Pages.
• pitch.json: every field.

Running a pitch

• Brand and next steps, Running a pitch, Analytics and the pipeline, The community and Teams and invites.

Reference

• MCP tools, CLI, HTTP API, Room events and Errors.

When something is wrong

• Troubleshooting, Security and privacy and the FAQ.