Lovio is a Swedish wedding-planning tool. The product looks calm. A guest list, an RSVP page, a seating chart, a budget. The operational shape is anything but. Most weeks are quiet. Then a Saturday arrives and a few hundred guests across half a dozen weddings start hitting SnapShare at the same moment, uploading photos from church basements with two bars of signal, while the couples' photobooth slots are being reserved live.
The asymmetry
If something breaks on Tuesday at 11am, I refund, apologize, and the user re-enters a guest. Annoying. Survivable. If the same thing breaks on Saturday at 3pm during their ceremony, I have ruined a day they will remember for the rest of their lives.
Most SaaS treats availability as a flat number. Lovio can't. Availability here is a function of the calendar.
Saturday afternoon is sacred. Everything I ship is judged against the question: would I deploy this on a Friday at 4pm?
What that actually changes
The biggest day-of load surface isn't the guest list. It's SnapShare, the photo-sharing feature couples use during the ceremony, and the photobooth that pairs with it. Photobooth slot reservations have to be atomic, so I do them as Firestore transactions. A botched deploy mid-Saturday cannot double-book a slot or hand out one the couple has already used up.
The other risky surface is subscription billing. Photobooth limits are computed from the couple's Stripe tier. If a Stripe webhook lags after an upgrade, a paying couple can hit a hard cap during the reception. That is the failure mode I check first whenever something feels off on a Saturday.
I don't deploy on Fridays, and it isn't a written policy. By the time I'm tempted, I've already remembered who's getting married this weekend.
It's a small product. The constraint is enormous. And it has taught me more about real availability than ten years of generic SLO conversations.