Ten seconds is a long time on stage

Knowing the song is only part of the job. On stage I might need the lyrics, the key, the tempo, the set order, a transition into another song, or a note somebody changed in rehearsal. None of it lived together: the setlist somewhere, lyrics somewhere else, a change sent through WhatsApp, a song saved in Notes, and the key in my head, usually.

Playwell is an iPad-first performance and setlist workspace for musicians: songs, lyrics, keys, tempos, artists, mashups, events and bands. I designed it and built it, specifically so I could find out what a design decision costs three days later on a stage.

There are excellent tools for listening, reading lyrics, sharing files and taking notes. My job during a performance was never “find this song”. It was “tell me what I need to know about this song, right now, without pulling me out of the performance.”

The reframe

“Not a better music app. A workspace with a very specific tolerance for latency.”

Underneath Playwell are three moments rather than a set of screens: prepare, find, perform. Every feature has to justify itself against one of them, and the interface gets less demanding exactly as the environment gets more demanding.

Prepare→Find→Perform

Each flow answers one of the questions I kept protecting.

I could use the product in the exact place the problem happened, so instead of running a study I documented friction where it occurred across the four moments of a performing week: before a show, rehearsal, performance, and after. The loop of perform, notice, change, use again has run through every version.

Each came from the product failing to describe the world correctly.

Scrolling is fine at fifty songs and a failure at two thousand. So there are multiple paths into one library, and the rule that keeps it coherent is to never duplicate information. Favorites isn’t a folder you copy into, events don’t own their songs, and artists aren’t a second database.

Early versions showed every control and field. That worked at a desk and stopped working the first time I used it in low light with a song playing. Search became the primary way in, key, tempo and time signature collapsed behind More filters with a count badge, and edit controls moved away from performance controls entirely.

My first model was an event as a list of songs. Real shows broke it inside one night: if a change costs more than living with the error, people live with the error. So events became something you create, arrange, adjust, perform and reuse, with two views that always agree.

53 of the 99 records in the bundled library are multi-section. More than half of what I perform isn’t a song, it’s a sequence. A mashup became a relationship between songs, and sections link to a standalone source song so a typo fixed once is fixed everywhere.

Cross-device sync shipped and did nothing. One line skipped any change authored by the signed-in user, to ignore the echo of my own writes. That’s correct until one person uses two devices. I had written user where I meant device, and every consequence followed correctly from that one wrong noun.

I don’t have a usability percentage for Playwell and I’m not going to invent one. What I have is a product tested in the least forgiving environment I know, where a failure isn’t a metric, it’s a gap in a song.

1. 01

   Real performance use

   Shows, in front of people, in real time.

2. 02

   Rehearsal use

   Where most setlist changes actually happen.

3. 03

   Large-library testing

   Around three thousand songs, not the twenty a demo would use.

4. 04

   89 automated browser checks

   Zero uncaught errors required to pass.

5. 05

   Feedback from other musicians

   The first signal from outside my own head.

It changed every time reality disagreed with me, and each stage answered exactly one question. I built it with no framework and no bundler, offline-first with Supabase and row-level security, so a design decision reached the stage within about three days.

Playwell started because I understood the problem intimately. That gave me speed. It also gave me bias, and the two are difficult to separate.

1. 01

   Familiarity hides friction.

   I could tolerate interactions because I knew how they worked, and read labels because I wrote them.

2. 02

   Assumptions surface outside your head.

   A real library size, a real stage, a real second device and a real bandmate each broke one.

3. 03

   The next phase needs the opposite.

   Less intuition, more external validation: can another musician perform with it without me explaining it?

Built because I needed it. Still changing because I use it.