Case study: Voice-Controlled Teleprompter

The page scrolls itself, because it is listening to you.

This is a free teleprompter for anyone recording video: one device (a laptop) holds and edits the script, a second device (a tablet or phone) shows it to the person on camera, and the page auto-scrolls and highlights the current word by listening to the reader's voice through the browser's own speech recognition. Two devices connect with a 4-digit room code, no account, no sign-up. We built the remote-control and voice-scrolling layer on top of an open-source foundation and left it running, open for anyone to use.

The numbers, and how to check them

From the review of the live codebase and production deployment, 2026-09-18.

4-digit

room code, no account, no data saved beyond the session

try it live at teleprompter.coscore.us

1 hour

a room lives with no connected devices before it disappears

server-side idle timeout

0

database tables: every room lives only in server memory

grep -i "CREATE TABLE" server/main.py → nothing

2

languages: Russian and English, auto-detected from the browser

switch from a gear icon on the display screen

What it actually does

  1. Authentication and roles. None. Rooms are anonymous, matched by a 4-digit code. Inside a room there are two roles. Control writes and edits the script and sends commands, Display shows the text and listens to the microphone. The role is picked by which URL a device opens, with no server-side login behind either.
  2. Data. No database at all. A script exists only in server memory for as long as the room does, capped at 256KB, and disappears once the room is idle for an hour.
  3. Real time. A WebSocket relay held in server memory synchronizes cursor position and script text between the two connected devices as the reader speaks.
  4. Integrations. None external. Voice recognition runs entirely on the browser's own built-in speech API. There is no separate speech-to-text vendor anywhere in the stack.
  5. Security. A room with no connected devices expires after an hour; the script has a hard size cap; there is no content moderation because the service never stores or publishes anything past the session.

What it is not

The part that makes the rest of this page checkable.

No account, no history

Close the tab and the session is gone. There is nothing to log back into and nothing of yours stored on our server past that hour.

Chrome's own speech recognition, not a dedicated engine

Voice input runs on the browser's built-in Web Speech API. There is no separate transcription vendor behind it, which also means accuracy depends on the browser you use.

Paused, not abandoned

Active development has been quiet since August 2026. The service still runs in production and stays live.

Built on an open-source foundation

The project started as a fork of an open-source, MIT-licensed teleprompter, with remote control, Russian recognition and the self-healing pieces below added on top.

Engineering decisions worth explaining

  1. Two capture modes, both kept on purpose. By default the microphone listens on the Display device, since browsers require a user gesture there anyway. But desktop Chrome recognizes speech noticeably better than mobile Chrome, so there is a second mode where Control's device listens instead and streams the recognized position to Display over the same WebSocket. Both modes stay in the code; neither is dead weight to be cleaned up.
  2. A rate limit against a runaway scroll. An unbounded matcher can project the recognized speech onto the wrong point in a long script all at once, which looks like the page jumping several paragraphs ahead on mobile recognition. The fix is a simple wall-clock limiter: the reading position cannot physically move faster than a person can plausibly read out loud.
  3. A self-healing speech recognizer. The browser's speech API is not built for continuous use: it tends to hang or slow down after roughly ten minutes. A watchdog restarts it with backoff on failure, fully recreates it after repeated errors, and rebuilds the session on a timer as a precaution before it degrades.
  4. No database, as a design choice. Nobody's script outlives an hour of inactivity. That is simpler to run (no schema, no migrations), and it is also the honest positioning: a tool for one recording session, not a place to store a script long-term.

Why this matters if you are hiring us

This is a small, free tool, and that is the point: we ship things that just work and give them away when there is no reason not to. The same care that keeps a room's data out of a database it does not need also shows up in how we scope the software we build for clients: simple where simple is honest, not complex for its own sake.

Tell us what's slowing you down.

We reply the same business day.