Never Lose a Second

Most apps can ask you to try again. Patron can't. By the time a session ends, the moment it captured is gone — the conversation, the formula, the "how was the wedding?" If the recording doesn't make it from the phone to our servers, there is no second take. The client has left the chair.

That single constraint — you get one shot — shapes more of our engineering than anything else. It turns "save the audio" from a checkbox into a design problem with three separate adversaries. The phone. The network. And, surprisingly often, the user.

Three things that want to lose your audio

The phone is a hostile environment for a long-running capture. iOS can terminate a backgrounded app to reclaim memory. A session can run for hours. The user might lock the screen, take a call, or the OS might decide your app has had enough resources for now. Any of these can happen mid-recording or mid-upload.

The network in a barbershop or salon is rarely the network in a demo. Shops live in basements, in the back of buildings, behind thick walls, on overloaded café Wi-Fi next door. Uploads start and stall. Connections drop at 90%.

The user is the one we underestimated at first. Plenty of people habitually swipe up and force-quit every app the moment they're done with it. To them it's tidiness. To a naïve "upload when the app is open" design, it's a guillotine.

You cannot prevent any of these. So the entire architecture is built around a single assumption: all three will happen, routinely, and the audio still has to survive.

The rules that fall out of that

Once you accept that the app will be killed and the network will vanish, the design almost writes itself. A handful of rules do all the work:

1. The disk is the source of truth, not memory

Audio is written to a file on disk as it's captured — never accumulated in memory waiting for the end. An early version of the app did the opposite: it held the recording in memory and then made a second copy to upload, briefly doubling the footprint. On a long session that was enough to trip the operating system's low-memory killer — and the app would die holding the only copy of the audio. The fix was a principle we've never broken since: stream from disk, never buffer the whole thing in RAM. Memory is borrowed; the disk file is yours.

2. Store it somewhere the OS won't sweep away

Operating systems offer "cache" directories they're free to purge under pressure — convenient, and exactly wrong for something irreplaceable. Pending recordings live in durable storage the system won't reclaim behind your back. The file outlives the app process, the upload attempt, even a reboot.

3. A confirmed upload is the only thing that deletes the file

This is the rule we're most stubborn about. The local audio is not deleted when the upload starts, or when it probably finished, or after some timeout. It is deleted when, and only when, the server has acknowledged it has the bytes. Until that handshake, the recording stays on the phone — through retries, through app restarts, through days of a flaky connection. Audio is never thrown away on optimism.

4. Resume is automatic, not a button

The upload queue is persisted to disk. Every time the app launches or returns to the foreground, it asks a simple question — "is there anything here that hasn't been confirmed?" — and quietly picks up where it left off. A force-quit mid-upload isn't an error state the barber has to recover from. It's a pause. The next time they open the app, the work is already finishing. They never knew it stopped.

5. Keep working while the screen is dark

When the app goes to the background mid-upload, it asks the OS for a window of time to finish the handful of bytes still in flight, rather than abandoning the transfer the instant the user looks away.

The pro should never see the machinery

All of that is invisible by design. When the pro taps stop, we don't show a blocking "Saving… please wait" screen — the next client is already in the chair, and a spinner that holds them hostage is its own kind of failure. Instead, they land right back on their day, and the just-finished session appears at the top of the list as a tile that quietly narrates its own progress: saving, then processing, then done. The tile is the confirmation. The reliability work happens entirely behind it.

The best reliability engineering is the kind the user never notices, because the only way they'd notice is if it failed.

The long-session problem

Some sessions run two or three hours — a long color, a detailed appointment, a chatty regular. That breaks a different set of assumptions. Transcription services have hard limits on how much audio they'll take in one request. A three-hour file doesn't fit.

So a long recording is split into ordered segments, transcribed piece by piece, with each finished piece checkpointed as it completes. That checkpoint does two jobs. It means a failure halfway through doesn't restart the whole thing — a retry resumes from where it stopped, re-doing only the pieces that didn't make it. And it means that if one segment genuinely can't be transcribed, we can continue with a visible gap rather than failing the entire session. A barber would much rather have 89% of a three-hour appointment with one honestly-marked "[a stretch here couldn't be transcribed]" than lose all of it because one chunk choked.

That word — honestly — matters. A gap is shown as a gap. We never silently drop a piece and let the barber believe the transcript is complete.

When you can't recover, say so

The flip side of "never lose audio" is refusing to lie when audio is lost. There's a rare case where a recording is abandoned before any audio ever reaches our servers — and for that session, there is genuinely nothing to recover. An earlier version of the screen still cheerfully offered to "retry" and reassured the barber that "your audio is safe." It wasn't, and the retry could only ever fail.

We fixed it to tell the truth: this recording didn't capture anything, here's a button to delete it, no false hope. Reliability isn't only about saving what can be saved. It's also about being honest, instantly, about what can't.

Why we sweat this

A stylist will forgive a lot. A slightly awkward screen, a feature that's not there yet, a reminder that goes out an hour late. The one thing they will not forgive — the thing that ends the relationship on the spot — is doing a great service, having a great conversation, tapping the button, and watching it evaporate. You only get to lose someone's work once.

So the queue persists, the file survives the process that made it, and nothing gets deleted on optimism. The pro just sees their session show up in their list, every single time. The fact that the phone died, the Wi-Fi dropped, and they force-quit the app on the way out the door is our problem — and we'd like to keep it that way.