The problem with live-show software
In a live show, the software either works perfectly or it fails in front of an audience. That standard is why professional show-control systems are expensive, proprietary, and often tied to dedicated hardware. Smaller productions — a theater, a house of worship, a corporate event, a touring band — get priced out, and end up coordinating cues over a group chat and a stopwatch.
The tools that are affordable usually want a server, a database, and an install process. On a show site with flaky WiFi and no IT staff, every one of those is a thing that can break at exactly the wrong moment.
What we built
ShowPulse is a complete show-control platform that ships as a single 4.1MB file. It reads the show's master timecode, tracks a cue list for every department, and pushes live countdowns to every crew member's phone or laptop — all from one binary you copy to a machine and run. No installer, no database, no internet.
- Reads the real show clock. It locks to industry-standard SMPTE LTC and MIDI timecode, so cues fire against the same master the audio and lighting run on — frame-accurate, not "roughly now."
- Every department sees its own cues. Sound, lighting, video, stage — each gets a live countdown to their next move, with color-coded urgency, on whatever device they're holding.
- Runs on local WiFi, offline. The crew connects to the one machine over the local network. No cloud round-trip means no lag and no dependency on a venue's internet.
- Five permission roles. From view-only crew up to the show caller who holds the timer lock — the right people can drive, everyone else can follow safely.
- Zero runtime dependencies. Built in Rust, with the entire web interface embedded inside the binary. There is nothing else to install, and nothing to fall out of sync.
Why a single binary matters
| Item | ShowPulse |
|---|---|
| Install footprint | one 4.1MB file |
| Database / server to run | none — JSON file on disk |
| Internet required at showtime | no — local WiFi only |
| Cost vs. proprietary systems | ~1/10th |
A single binary isn't a gimmick — on a live show it's the whole reliability story. There's no install that can go wrong on the day, no database that can corrupt, no version drift between machines. You copy one file, double-click it, and the system is up. If it needs to move to another laptop mid-event, that's a thirty-second copy, not a re-install.
What we learned building for a live audience
- Rust earns its keep where failure is public. The same properties that make Rust strict in development — no null surprises, no data races — are exactly what you want when the software is running a show in front of a paying crowd.
- Embedding the frontend removes a class of bugs. Baking the entire UI into the binary means the interface can never be a mismatched version of the server. One file, one truth.
- Timecode belongs on its own thread. The clock sources run isolated from everything else, so a busy web request can never make a cue fire late. The engine recomputes on exact second boundaries and caches in between.
- 84 tests, because you can't hotfix a live show. The whole API is covered by an automated suite, because the only acceptable time to find a bug is before the doors open.
Where this applies
If you run timed, cue-driven events and the professional tools are out of reach — or overkill — this fits:
- Theaters, live music, and touring productions
- Houses of worship with multi-department services
- Corporate events, conferences, and award shows
- Any crew currently running cues on a stopwatch and a group chat
No servers, no subscriptions, no venue-internet dependency. One file that turns any laptop into a show-control system.
Running a show on a stopwatch and hope?
Let's talk about what frame-accurate, self-owned show control would look like for you.
Talk to Us