Bandpit

Bandpit began as a shared songbook. That asked a band to do a lot of work before it could discover whether the product helped: import the repertoire, organise the arrangements, then get everybody into the same session. The next gig offered a better starting point.

A musician can add a date, venue and lineup, publish the show and make its promo from the band's own photographs. That is useful before a single song has been imported. Building the set becomes the next piece of work for a show that already exists.

I designed and built the product end to end. Twenty years of making record sleeves and posters for bands informed the public side; the rehearsal room set the requirements for the private workspace and Live.

The gig connects a public event page, the artist bill, promo artwork and the private working set. Songs can arrive as a quick list, pasted charts or imported files. A set's estimated duration helps the band judge whether it fits the slot before everybody meets to rehearse.

Each setlist item pins a particular arrangement. Editing a song later does not silently replace the version chosen for that show. Several bands can share an event while keeping their own sets private and under their own control.

The desktop rail belongs to the band, so Gigs, Songs, Setlists and Live remain in the same place. The public artist page has a different job: photographs, music, booking and dates should belong to the artist. The same application supplies both without turning the public page into a dashboard.

The early scrolling model moved a fixed number of pixels per beat. It made a section's duration depend on the amount of text and the width of the screen. An instrumental break with no lyrics could have almost no duration at all.

The current model gives each section its own bar count. Bars, time signature and tempo determine its duration; the screen maps that musical position onto its own layout. An eight-bar section in 4/4 at 120 BPM lasts sixteen seconds whether a musician opens one content pane or three.

The realtime service supplies a shared clock anchor. Each device calculates its position locally rather than receiving a stream of pixel offsets. Section cues seek to a point in the musical timeline, so the conductor's screen width no longer determines where another phone lands.

Bands that do not play to a click can use Step mode. The conductor advances one section at a time and the other screens follow. Scroll and Step share the same playhead, which keeps cues and recovery consistent between them.

Choosing a song or set prepares the shared screen. It does not start the clock. The conductor starts Live when the band is ready; Scroll mode then gives the selected one- or two-bar count-in before the first section.

Moving to the next song returns to Ready. Rejoining an active session restores its current position, while a completed session is retired instead of reopening at the bottom of the previous song. These are small transitions, but they decide whether the tool feels dependable between songs.

A working set contains things an audience does not need: charts, keys, tempos and private notes. The post-gig archive therefore publishes a snapshot of song titles and encore flags. It contains neither the charts nor references that let a visitor retrieve them.

Each artist decides whether to publish its own set after the show. An event organiser cannot publish another band's private material. Changing the working set later also leaves the public snapshot alone until the band deliberately republishes it.

The EPK reuses explicitly public material. A booking enquiry becomes a message in the band's private inbox. Fan updates require confirmation and a choice of city. Those boundaries let the public side grow around the work without making the band's workspace public by accident.

A Pro band can save a pinned set and its selected backing tracks to one trusted browser before the show. That prepared device can run Scroll or Step, cues and audio locally for seven days before an authenticated refresh is required.

This is a fallback for one output device. The other phones still need their realtime connection; offline multi-device synchronisation would need another transport. Keeping that limit explicit matters more than giving the feature a broader name.

Backing tracks also use one designated output device. The other screens follow the shared musical clock without playing another copy of the audio. The local player handles count-in, pauses and cues against that same position.

The subscription belongs to the band. Its members share the catalogue and access rather than buying the same workspace one seat at a time. The free tier includes ten songs and a real single-song Live session; Pro adds full sets and the wider stage tools.

The web app runs on Vercel, the realtime service on Fly.io and the database on MongoDB Atlas, with those services placed in Stockholm. Private rehearsal audio and backing tracks use a separate R2 bucket. Public pages never expose that private audio store.

The gig-first workflow and stage tools are implemented. The next test is repeated use by whole bands, across rehearsals and shows. A prepared screen or one curious visit is not enough to establish that.

The owner dashboard separates a session that was prepared from one that actually started. It can track repeat Live use and participation alongside show readiness and public-page activation. The new measurements have explicit starting dates, so old sessions are not retroactively turned into adoption data.

This case describes product decisions and working software. It does not claim a scale of adoption or revenue that I have not established.