RoomReady

Know what's ready before you go live. RoomReady checks your microphone, audibility, and app connection, turning real measurements and user confirmations into an evidence-backed soundcheck receipt.

Comment

Inspiration

Every online lesson, workshop, interview, or presentation starts with the same uncertainty: Is everything actually working?

A microphone can show activity without producing intelligible speech. Speakers can appear connected without anyone confirming they can hear audio. A successful network request does not guarantee that a meeting platform will work.

Most pre-session checks provide a simple green indicator. But what was actually tested? What was assumed? And what happens when someone changes a setting afterward?

We built RoomReady to make those distinctions visible.

The idea is straightforward: Don't just tell someone they're ready. Show them the evidence.

What it does

RoomReady is a browser-based, evidence-backed soundcheck designed for people preparing to teach, present, or host a workshop.

Instead of generating an unexplained ready/not-ready verdict, RoomReady produces a structured readiness receipt.

Its workflow includes:

  • Microphone check: With explicit permission, RoomReady analyzes a three-second microphone sample and measures its audio level.
  • Local playback: Users replay their recording and personally confirm whether it sounds clear. Raw audio remains in the browser.
  • Speaker check: A quiet test tone plays, and the user reports whether they heard it.
  • Connection check: Five actual requests measure response times against RoomReady's own endpoint.
  • Evidence receipt: Measurements, user confirmations, unresolved conditions, and limitations appear separately.
  • Adjustment tracking: Changing a setting reopens affected checks instead of preserving potentially outdated confirmations.
  • Privacy controls: Receipts can be exported or cleared, expire after 24 hours, and never contain uploaded raw microphone recordings.

For example, if network response times exceed the configured threshold, RoomReady does not pretend the connection passed. It reports the check as UNRESOLVED.

This is intentional. We believe uncertainty should be visible rather than hidden behind a reassuring status indicator.

How we built it

RoomReady combines browser-native audio capabilities, a real Model Context Protocol (MCP) workflow, and cloud-backed evidence storage.

Frontend and audio

TypeScript, Vite, the Web Audio API, and MediaRecorder power the browser experience. The application analyzes audio locally, supports recording playback, generates a speaker test tone, and performs actual endpoint timing.

Backend and MCP

Node.js and Express provide isolated browser sessions, schema validation, revision checks, and idempotent operations.

Four MCP tools support recording observations, tracking adjustments and withdrawals, and retrieving evidence receipts.

Cloud infrastructure

The application is deployed over HTTPS using Google Cloud Run. Google Cloud Storage securely persists structured session evidence. Storage operations use generation preconditions, helping protect evidence from conflicting updates. SQLite supports local development.

Readiness logic

A deterministic TypeScript evidence model separates measured observations from user confirmations. Changing an affected setting invalidates the earlier check, while historical observations remain visible.

The guide does not require a generative model to decide whether evidence exists.

Challenges we faced

1. Measuring something is not the same as verifying it.

Microphone activity cannot prove speech intelligibility. A generated speaker tone cannot prove a person actually heard it.

We addressed this by separating instrument measurements from explicit human confirmations.

2. Preventing misleading readiness results.

An earlier successful test should not remain valid after a relevant setting changes.

We implemented revision-aware evidence handling and adjustment invalidation so that affected checks must be reconsidered.

3. Privacy without sacrificing useful evidence.

Audio recordings can contain sensitive information.

We kept raw audio in the browser while storing structured observations separately. Receipts expire after 24 hours, and users can explicitly clear them.

4. Testing audio without dependable microphone hardware.

The automated test environment could not perform physical microphone capture.

Instead of claiming hardware verification, we used explicitly labelled synthetic Web Audio inputs to exercise analysis, recording, replay, and receipt behavior. Real-device listening remains a separate verification requirement.

5. Making cloud persistence reliable.

We tested idempotent retries, stale revisions, session isolation, rejected origins, evidence deletion, and persistence across an actual Cloud Run revision replacement.

Accomplishments and verification

RoomReady has a publicly accessible deployed application with genuine MCP-backed evidence operations.

Testing included:

  • 42 passing Node.js tests.
  • 22 desktop and mobile browser scenarios.
  • 16 frozen synthetic receipt scenarios matching expected outcomes.
  • Real deployed MCP initialization and four working tools.
  • Cloud-backed session persistence, export, and deletion.
  • Validation of adjustment invalidation and stale revision rejection.

In a deployed connection test, five actual endpoint responses produced a median of 344 ms and a p95 of 349 ms.

Because this exceeded the configured 300 ms threshold, RoomReady correctly preserved an UNRESOLVED result rather than manufacturing a successful check.

That behavior represents the product's core principle: A trustworthy tool should report inconvenient evidence accurately.

What we learned

The central engineering lesson was that a trustworthy readiness system needs three distinct concepts:

  1. Observation: What the system actually measured.
  2. Confirmation: What a human explicitly verified.
  3. Uncertainty: What remains unknown or cannot be established.

Keeping those concepts separate makes the resulting evidence more transparent, auditable, and useful.

MCP also provided a structured way to manage browser-generated evidence without requiring raw audio to leave the device.

Alexa+ experience and scope

RoomReady explores an Alexa+ experience concept through a clearly labelled browser simulation, using a real browser MCP client.

It does not claim native Alexa device integration or a deployed Alexa skill.

It also does not directly test Zoom, Teams, remote participants, camera hardware, or operating-system settings. An optional Amazon Bedrock advice component exists in code but is disabled and has not been live-verified.

Automated audio tests used synthetic inputs; successful physical microphone capture and human listening are not yet independently verified.

These limitations are intentionally disclosed rather than hidden.

What's next

The next improvements are real-device verification across more browsers and hardware, clearer guidance for resolving failed checks, expanded accessibility testing, and investigation of native voice-assistant integrations.

The longer-term opportunity is to make evidence-backed pre-session checks a normal part of starting any virtual interaction.

RoomReady isn't about promising that everything will work. It's about helping people know what has actually been checked before they go live.

Try RoomReady: https://roomready-kc4mxxrtbq-uc.a.run.app

Built With

Share this project:

Updates

Submission history