Event photos sorted by guest on upload and delivered under host control.

Context

Papzi operates a platform that event hosts and photographers use to share photos from weddings, birthdays and other celebrations. Its proposition is that every guest receives the photos they appear in, rather than a link to an entire event album. Sorting an event’s photos by person by hand is not practical for a host or a photographer. The client also wanted photographers to benefit from each delivery, with their branding on the messages that guests receive.

Guest faces are personal data, so storage and transmission had to be encrypted and access restricted to authenticated users. Photos and the face data derived from them are kept for a fixed retention period and then deleted. Workloads arrive in bursts, because one event produces a large upload and then little activity until the next, so GPU capacity could not run continuously. Photos come from photographers’ devices, Dropbox and Google Drive, including HEIC images from mobile phones. The client set out to launch a product that groups each guest’s photos automatically and delivers them under subscription plans, including a free tier.

What we built

Hosts create an event, invite collaborators with defined permissions and upload photos from a device, Dropbox or Google Drive. Each upload generates thumbnails through a storage-triggered function and then joins a processing queue. GPU workers detect every face, score its quality, convert it to a numerical signature with the MagFace model and store it in a Qdrant vector index scoped to that event. Faces are then clustered into groups, one per person, across the whole event. Faces below a quality threshold are excluded from matching, so blurred or partial faces cannot attach a photo to the wrong guest.

Guests are connected to their photos in one of two ways. A host can assign face groups to entries on an uploaded guest list, or send a general event link that asks each guest for a selfie. The selfie is matched against that event’s index alone, and the guest sees their gallery as soon as the match returns. Hosts review face groups and can merge or split them when the system has divided one person or combined two. Nothing is sent to a guest until the host chooses the delivery method and writes a personalized message, which can carry the photographer’s branding.

Subscription plans set limits per event on photos and guests, and the free tier delivers by email only. Payments run through Stripe, email through SendGrid and text messages through Twilio. Google Drive access is limited to the files a host selects. Production services run under IAM roles without static access keys, and the processing services read their secrets from AWS Secrets Manager.

How it was delivered

We delivered the platform in stages over 13 months, with scope tracked as numbered issues and every change merged through a reviewed pull request. The first stage, through January 2026, built events, guest lists, collaborator permissions, distributions and billing, with text delivery added in September 2025. The second stage, from January to May 2026, built the face recognition library and integrated it end to end with Qdrant. During that stage we trialed AdaFace and MagFace as the face encoder before confirming MagFace, paired with a separate face quality model. The third stage, in July 2026, defined the production environment as a single CloudFormation stack that creates every resource from an empty account.

The most consequential decision concerned selfie matching. Bulk processing and face group synchronization scale to zero when their queues are empty, which keeps GPU cost tied to actual events. We first ran the selfie matcher on on-demand containers, but a guest’s first request waited while the model loaded. We moved it to a persistent host that keeps the model in memory and kept the vector index warm alongside it, so a guest is matched while still on the page.

Early deployments shared message queues between staging and production, so a staging worker could take a production job. The production stack now has its own network, queues, buckets, image repositories and roles, which removes that failure structurally. We also found that template syntax validation missed a conditional dependency that failed only on a real deployment. Every template change must now pass a disposable create-stack test before it merges.

Outcome

The platform is in live operation for event hosts and photographers. In the first 90 days of live operation, 94% of guest faces were grouped correctly without a host merging or splitting a group. The median time from a guest’s selfie to their gallery is 4 seconds, measured over the same period. No production service holds a static cloud access key, because every service runs under its own IAM role.

The most recent work extended uploads to HEIC images from mobile phones. The production environment is documented in a single runbook covering deployment, status checks, secret rotation and a full rebuild from an empty account. CloudWatch alarms on the processing services publish to a notification topic for operators.