My friend Priya runs the scheduling for a 34-bed medical floor and has spent two years fielding shift-swap requests over a group text that nobody reads in order. She wanted something nurses could open on a phone during a break, post a shift they need covered, and have someone claim it before the charge nurse has to manually reshuffle the board. I built it over three weeks of evenings. This is the log of the day it actually went live — publish, custom domain, real nurses, real shifts — because the gap between "it works in testing" and "it works at 7am when the floor is short two people" turned out to be its own kind of lesson.
6:58am — publish
I'd set the deploy target to Priya's own domain the night before, so this part was anticlimactic: hit publish, watch the build's verification record run through its checks — routes resolving, the shift-claim endpoint returning a real response instead of a stub, the SMS notification hook actually configured instead of dry-run. All green. I texted Priya the link at 6:58am because I knew she'd be walking into her shift right then and I wanted her to see it live before the day started, not after.
7:15am — the first real user does something I didn't test
Priya posted an open shift for that evening within twenty minutes, which was faster than I expected and meant I hadn't finished my coffee before the first real data point existed. Then a nurse named Denise claimed it, unclaimed it four minutes later, and reclaimed it. I have no idea why — maybe she checked her own calendar mid-claim and realized she had a dentist appointment. The app handled it fine. What I hadn't tested was three people trying to claim the same shift within the same ten-second window, because in three weeks of solo testing that scenario never once occurred to me. It didn't occur to me now either. It occurred to reality about five hours later.
9:40am — quiet, and I get nervous about the quiet
Nothing happened for two and a half hours. No claims, no posts, no errors in the logs. I checked the dashboard four times anyway, which is a habit I should probably break — a build that isn't being used isn't broken, it's just not being used yet, and those are different problems with different fixes. I made myself close the tab and go do actual work.
11:52am — the bug
Three nurses claimed the same shift within six seconds of each other. The claim endpoint accepted all three, because I'd written the "mark as claimed" logic as a straightforward update-if-open check without a lock, and under normal single-user testing that race condition simply never has room to happen. Under three simultaneous taps from three different phones, it has plenty of room. All three nurses got a confirmation text saying they'd covered the shift. Denise was one of them, for the second time that day, and this time she was annoyed.
I want to be honest about how I found this — I didn't catch it from monitoring. Priya texted me "app says 3 people got the same shift lol" with a laughing emoji that I don't think she meant literally, because it was, in fact, a problem for her afternoon.
12:10pm — into the build chat
I described the bug in plain language: multiple people can claim one shift if they tap around the same time, and only one claim should stick. I didn't try to write the fix myself first, partly because I was on my phone in a parking lot and partly because describing the failure precisely is usually faster than diagnosing it precisely. The agent traced it to the missing row lock on the claim table, proposed switching to an atomic conditional update — claim succeeds only if the shift's status is still "open," and the operation itself decides who wins instead of a check-then-write that lets three requests all see "open" at once. That's the actual bug in one sentence, and it's the kind of thing that's obvious once you say it and invisible until something forces it into view.
12:34pm — the fix goes out, and I make Priya wait
The patch was small. I still didn't push it straight to the live domain during an active shift — I ran it against a preview version first and had Priya's charge-nurse colleague, who wasn't on shift, try the same three-taps-at-once thing from three browser tabs. It held. One claim went through, two got a "this shift was just claimed by someone else" message instead of a false confirmation. I pushed it live at 12:34pm, about forty-two minutes after the bug happened, which felt slow in the moment and fast in retrospect.
2:00pm through 6:00pm — the boring, good part
Eleven more shifts posted. Nine claimed cleanly, two expired unclaimed and rolled into the board Priya still manages manually, which is fine — the tool doesn't need to solve everything on day one, it needs to solve the specific thing that was broken. No more double-claims. I watched the numbers instead of imagining outcomes, which is a different and much calmer activity.
What I'd do differently
Two things. First, I'd have described the concurrent-claim scenario in the original build prompt instead of discovering it live — "multiple users, same action, same moment" is a sentence, not a hard ask, and I just didn't think to include it because my own testing is inherently sequential; I only ever click one button at a time. Second, I over-invested in the SMS notification wording during week two — three separate rewrites of a confirmation text nobody complained about — and under-invested in exactly the kind of concurrency edge case that a floor full of nurses on break, all staring at their phones at the same moment, was always going to hit on day one. Next launch, I'm spending less time polishing copy nobody's going to critique and more time asking "what happens if five people do this at once," because for anything with more than one real user, eventually, someone will.
