Works·deprecated

Eventflow

Turning the invisible into seen

A platform that delivers event photos directly to the people in them.

An Eventflow event page: the group number to text photos to, and a short form to join with a name, phone and one profile photo
The event page. Guests join with one selfie, then text photos to the group number.
A guest's private Eventflow gallery: the 29 photos they appear in, each sent by a different guest or imported from a shared album
A guest's private gallery, assembled from everyone's photos.
The Eventflow organizer view: guests joined, photos received, faces matched and texts sent, with a guest list and the latest photos
The organizer view during an event: who has joined, what has come in and who has been found.

The problem

Take a group photo at a party. Not everyone knows each other: someone brought a plus-one, someone just met the group. Someone always says "make sure you send me that," and the photo stays buried in one camera roll, never shared. The friction is small, but it's enough that it almost never happens. Eventflow was my attempt to remove it.

What I built

An organizer registers an event and gets a group phone number to pass around. Attendees join with a phone number, email and one profile photo. That photo is what every picture gets matched against. From then on, anyone at the event texts photos to the number, and each attendee gets a text when they appear in someone's picture, with a link to their own private gallery.

How it works

Two queues sit at the center: one for outbound texts, one for heavy processing like face matching and gallery building. An event router decides which work goes where, so each kind can scale on its own.

Eventflow architecture, top to bottom. An organizer registers an event through the web app and Event API and gets a group number, and the Event API queues a welcome text. A guest texts a photo to the event's number; the Message API puts it on the SMS queue, and the event router sends the heavy work to the processing queue and logs every text it sends. Workers match faces against profile photos, import shared albums and build the galleries: each photo is saved and added to the private gallery of every person in it, and each of them gets a text with a link.ORGANIZERSGUESTSAPIMESSAGE HANDLINGHEAVY WORKWORKERSDATAOrganizerregisters an eventGuestjoins with one profile photoWeb appregisters eventsGroup numberone per eventEvent APIcreates eventsqueues welcome textsMessage APItakes in textsSMS queuetexts in and outEvent routersends work whereit belongsProcessing queuescales on its ownFace matcheragainst profile photosAlbum importershared albumsGallery buildereach person in a photoEvent DBDelivery logevery text sentPhoto storagePrivate galleriesone per guest, linked by texttexts photoadds photo, texts linksavescreates eventlogs texts

The highlighted path follows a photo from a guest's text to the private galleries of the people in it.

Early on I weighed availability, consistency, durability, scalability and security against each other. A few of the decisions:

What was hard

Matching faces in real party photos. Guests give one clean selfie, but party photos are dark, blurry and taken from the side. A missed match costs little; a wrong one sends someone a stranger's photo and breaks trust. So the matcher only sent a photo when it was confident.

What I learned

I listened, and I heard the pain clearly: "I never get the photos I'm in." What I didn't test fast enough was whether that pain was something people would seek out, or pay for. People complained about it, but that didn't mean they would go looking for a fix.

Next time I'd test that before building.