About
We kept building things nobody could see.
Why Roomi exists, and what it would take to build it yourself.
For a long time, the hardest part of showing someone a thing we had made was not the making. It was getting it in front of them.
A working prototype is the most persuasive thing you can put in front of a person. It answers questions a description can’t. But a prototype on your own laptop persuades nobody but you, and every way we found of getting it off the laptop cost us something.
Everything we tried
We sent staging links, and they broke on the morning someone finally opened them, because somebody had deployed over the top. We recorded our screens, and the recordings were out of date by the next change, and nobody could click anything in them. We pasted screenshots into decks, which turned a working thing back into a drawing of one.
When none of that would do, we asked an engineer to put the demo somewhere. Then we waited, because they had real work to do, and a demo for someone outside the team was never anyone’s priority. When it did go up, it went up behind a password we sent in the same message as the link, and could never take back.
And then, nothing
The worst part came after we pressed send. We didn’t know whether it had been opened. We didn’t know by whom, or whether they got past the first screen, or which part made them lean in and which part lost them. If they passed it to a colleague, we never learned who that was. We found out how it had gone weeks later, in passing, or we never found out at all.
We were deciding what to build next on the strength of silence.
The building had become fast. The showing, and the hearing back, had not.
What changed
Then building got quick. With Claude, someone who isn’t an engineer can make a working prototype in an afternoon. That made the old problem worse, not better: far more things worth showing, and the same slow, blind way of showing them. The step after building had become the slowest one, and the one we knew least about.
Why we built Roomi
So we built the thing we kept wishing we had. You say one sentence to Claude, “deploy it to roomi”, and the demo you just made is live in a room: hosted, private, with a guided tour. Each person you send it to gets their own link, and you can expire or revoke any one of them on its own. Nobody technical has to put it anywhere.
Then you can see what happened. Who opened it, and the route each of them took through it. Where their attention went. The questions they asked, pinned to the screen they were on, with a picture of that screen. Who they passed it to, because a forwarded link asks the next person who they are. What they said when the room asked what happens next. Each person’s evidence sits beside their name, the pipeline moves on its own, and you can ask Claude about any of it.
The demos run on mock data, each in its own isolated container or as a static build, on a domain kept apart from ours. The people looking at them are real, though, and so is everything they tell you, and we treat it that way.
Build or buy
You could build this yourself. Here is roughly what it takes.
Every figure in this section is our estimate of the engineering time one experienced engineer would spend, built to a standard you would be happy to send outside your team. They are estimates, not quotes and not measurements: a team that has built something like it before will be quicker, and one that hasn’t may be slower.
| What you need | Build it yourself (our estimate) | Roomi |
|---|---|---|
| Getting it live | ||
| Hosting for each demoIsolated, so one demo cannot reach another | 2–4 weeks | Its own container, or a static build |
| A separate domain for demosSo a demo’s cookies cannot reach your product | 2–5 days | Included |
| Deploying from where you built it | 1–2 weeks | One sentence to Claude: “deploy it to roomi” |
| A guided tour through the demo | 1–3 weeks | Included |
| Sharing it | ||
| A link for each viewer | 1–2 weeks | Included |
| Expiring or revoking any one link | 3–5 days | Included |
| Knowing who a link was forwarded toA forwarded link asks the next person who they are | 1–2 weeks | Included |
| Knowing what happened | ||
| Who opened it, and each person’s journey | 2–4 weeks | Included |
| Where attention went, and each person’s evidence | 2–4 weeks | Included |
| Questions pinned to the screen they were onWith a screenshot of that screen | 2–3 weeks | Included |
| “What happens next?”, and a pipeline that moves by itself | 1–3 weeks | Included |
| Asking Claude about any of it | 1–2 weeks | Included |
| Keeping it safe and running | ||
| Security hardening | 2–4 weeks, then ongoing | Ours to do |
| Uptime and maintenance | 2–4 days a month, for as long as it runs | Ours to do |
Hidden costs
The parts nobody puts in the plan
These are what you meet once it is running and people outside your team are using it. Most of them never finish.
Security reviews
Anything that serves your unreleased work to strangers needs someone to look hard at every change to it. That review is time, every time.
Being on call
When a link fails the evening before someone’s meeting, a person gets the message. Usually it is the one engineer who built it.
Browser quirks
Viewers open links on old tablets, in the browser inside an email app, with tracking protection on. Each one is a new way for the demo, or the counting, to go wrong.
Link abuse
Links get forwarded, posted and scraped, and email scanners open them before any person does. Telling a real view from a robot’s is its own project.
Requests about viewer data
Once you hold viewers’ names, emails and what they did, they can ask to see it or have it deleted under GDPR. Someone has to answer, and the system has to make that possible.
Keeping demos apart
A demo’s code is untrusted the moment someone else writes it. It has to run away from your real systems, and on a domain of its own.
Updates that never stop
Frameworks, certificates, runtimes and dependencies all move. A system that is not kept up to date becomes the weakest thing you run.
The tool nobody owns
When the person who built it moves on, it keeps running, and nobody left quite knows how. Internal tools outlive the knowledge of them.
Time to value
From a finished demo to someone looking at it
With Roomi, it is minutes. Building it yourself, it is weeks before the first viewer, by the same estimates as the table above.
With Roomi
- Minute one
Say one sentence
In the chat where you built it, say “deploy it to roomi”. Claude rehearses it, shows you what would go live, and publishes when you say yes.
- Minutes later
Make a link for each person
Claude makes each viewer their own link. Send it however you like, and expire or revoke any one of them later.
- When they open it
They take the tour
The room walks them through the demo. A question goes on the screen they were on, with a picture of it, and a forwarded link asks the next person who they are.
- From then on
You see what happened
Who opened it, the route each person took, where their attention went, what they said happens next, and a pipeline that has already moved.
Building it yourself (our estimate)
- 4½–10 weeks
Hosting, a demo domain, a deploy path and a tour
Isolated hosting for each demo, a domain of its own, a way to get a build there, and a tour through it.
- A further 2½–5 weeks
Links and access
A link for each viewer, expiry and revocation, and some way of knowing who a link was forwarded to.
- A further 4–8 weeks
Tracking and analytics
Who opened it, each person’s journey, where attention went, and the evidence of who is leaning in.
- A further 4–8 weeks
The feedback layer
Questions pinned to the screen with a screenshot, an answer to what happens next, a pipeline, and a way for Claude to read it all.
- A further 2–4 weeks
Security hardening, then the first viewer
A review of everything that faces the outside, fixes, and only then a link you would send. In all, 17–35 weeks of one engineer.
- Every month after
Keeping it running
Two to four days a month of updates, fixes and answering for it, for as long as anyone uses it.
Total cost of ownership
The first year, in engineer-weeks
The estimates above, added up, with a year of keeping it running. A week here is five working days of one engineer. These are our estimates of engineering time, not quotes or measurements.
| Over the first year | Build it yourself (our estimate) | Roomi |
|---|---|---|
| Building it | 17–35 engineer-weeks | Already built |
| Keeping it runningUpdates, fixes and uptime: 2–4 days a month | 5–10 engineer-weeks a year | Ours to do |
| Security reviews and fixes | 1–3 engineer-weeks a year | Ours to do |
| Being on callNot counted here: it is someone’s evenings, not their weeks | Someone, out of hours | Not yours |
| What you pay us | Nothing | Free today |
| Paid plans, when they open | Nothing | Pro £4 a month; Team £5 a seat a month, for 2 to 5 seats |
| In all | ||
| Engineering time in the first year | 23–48 engineer-weeks | Minutes, to your first room |
| At an assumed £500 a dayOur assumption for one engineer’s day: put your own rate in. 23 to 48 weeks of five days, at £500 a day. | £57,500–£120,000 | £0 on Free |
Fair questions
- Are these figures measured?
- No. They are our estimates of the engineering time each piece takes one experienced engineer, They are not quotes, and they are not measurements of anyone’s project. Your own may well differ.
- When does building it yourself make sense?
- When showing work like this is your product, or it has to run inside your own network, or you need something we do not do. If so, the table above is a fair list of what to plan for.
- Do we need an engineer to use it?
- No. If you can build a prototype with Claude, you can deploy it: one sentence, “deploy it to roomi”, in the chat you built it in.
Organisation
Talk to us
For more than 5 people, or when you need more than a team plan gives you. Organisation is by arrangement: no checkout, no card. Start free, and we set it up with you: tell us what you need.
More than 5 people
Team covers 2 to 5 seats. Beyond that, we set the limits to fit your team.
Single sign-on
If your people sign in through an identity provider, tell us which one. What we can support is part of the arrangement.
Where the data lives
If viewer data has to stay in a particular region, say so at the start, so we can tell you plainly what we can do.
Audit history and your CRM
If you need a record of who did what, or what viewers did to reach your CRM, tell us how you work today.