Advance

Live music teams rely on clear technical documentation before a show reaches the venue. In practice, that documentation is often scattered across PDFs, spreadsheets, email threads, screenshots, and reused templates. For instance, a stage layout may live in one file while channel details, gear needs, and notes live somewhere else.

When the setup inevitably changes, multiple documents need to be updated by hand, and everyone in the crew needs the updated plan. That creates duplicated work and increases the risk of outdated or inconsistent information.

The challenge was to create a practical workspace where all technical documentation would live, stay in sync, and be accessible to everyone in the crew.

FOH engineers and production managers working with regional and national acts. These are the people who plan the technical details of a show; where everything on the stage is placed, how it's wired, and how it's connected to the audio system.

No budget. No team. No existing domain knowledge. This would be a test of my ability to learn and build a product from scratch.

I interviewed some friends in the industry to find out how they actually work: What docs are critical for the show, where the process often breaks down, what they like and dislike about their current workflows, and what features were on their wishlist. We also discussed what solutions they'd already tried, and why they weren't completely satisfied with them.

I was able to review real technical documentation from national touring acts, which showed me what data and formatting was actually used in production.

Unsurprisingly, there was a lot: Stage plots, input lists, snake tables, monitor patch information, RF frequencies, and more.

It would be crucial to do 2 things for this MVP:

1. Connect and sync data points where possible to reduce duplicated work
2. Identify the most important and common docs to include to ensure the project stayed focused

The most critical documents are the stage plot, input list, and snake tables. This would be the focus of the MVP.

We would include a gear library to store the most common stage items, like drum kits and guitar amps, as well as default settings for each item. This meant a user could drag a drum kit onto the stage, place it at the correct location, and have intelligent audio settings automatically populate the input list with microphone choices, stand types, and channel numbers.

To reduce duplicate work, the app would allow synced data points to be edited in multiple places so users could stay within the context they were working. It would also allow for the cloning and templating of certain advance types to allow for a quicker start and one-off show modifications. Sharing the documentation would be done via a read only link that was always up to date, as well as a pdf export for when the internet wasn't available.

Show details can change at a moment's notice, so the app needed to be accessible and responsive on all devices.

Everything above, built and in beta. The stage plot canvas, the gear library with real-world dimensions and default audio settings, the synced input list, snake tables, cloning and templating, always-current share links, and PDF export. All shipped and in the hands of beta users.

The parts that matter most in practice: dropping a gear item onto the canvas populates the input list automatically, so engineers start from a working draft. And because channels live in one place, editing from the input list or from the item itself keeps everything consistent so the same change never has to be made twice.

I set out to test whether I could learn an unfamiliar domain cold and ship a real product with no budget, team, or prior knowledge of live-production workflows. Advance is in beta with the full feature set built, which answers the question.

For me, the feature list isn't the most important part. It's that the build stayed anchored to how the work is actually done. Interviews shaped the scope, and feedback from working industry pros focused the MVP into a lean, useful tool.