Four hundred guests, and the AI knows which photos are theirs
A platform where event guests register with a selfie and automatically receive every photograph they appear in — built on AWS Rekognition and serverless processing, with album selection tooling alongside it.
Built for an association of event photographers. Client and platform not named.
- SECTOR
- Event photography
- AI
- AWS Rekognition
- STACK
- Laravel, Python, Lambda
- MODEL
- Subscription SaaS
- STATUS
- LIVE
The people in the photographs never see them
A wedding photographer shoots several thousand frames. The couple gets an album. Everyone else — the four hundred guests who travelled, dressed up and appear in hundreds of those images — gets nothing, because there has never been a practical way to work out which photographs belong to whom.
The manual version does not scale past a handful of people. Nobody is going to look through three thousand images to find the twelve containing a particular cousin, and dumping the entire gallery on four hundred people solves nothing while creating a privacy problem.
This is a recognition problem, and until recently the answer was to accept it could not be solved.
Facial recognition changes that completely, and the change is commercial rather than technical. Guests who receive their own photographs have seen the photographer's work and know whose it is. An event stops being one client and becomes several hundred people holding evidence of what this photographer can do.
How the matching works
Guest opts in at the event
A guest registers with a phone number and a selfie. Deliberate, at the venue, in exchange for something they want — which is a far better consent position than capturing faces passively.
Photographer uploads after the event
The event's images enter the platform once shooting is finished.
Faces indexed across the event
A serverless Python pipeline processes the set, detecting and indexing every face into a collection scoped to that single event.
Registered selfies matched against the index
Each guest's registration selfie is compared against the event collection, producing the set of images that guest appears in.
Delivered to the guest
Matching photographs are sent to the number they registered with. The guest does nothing after registering.
Why event-scoped collections matter
Faces are indexed per event rather than into one global collection. A guest at one wedding is not searchable against another photographer's event, matching accuracy improves because the candidate pool is small and contextually related, and an event's biometric index can be disposed of as a unit when it is no longer needed.
That last property is the one that matters most, and it was a deliberate choice rather than a convenient side effect.
Facial data deserves a straight answer
This feature processes biometric data about members of the public. Under India's Digital Personal Data Protection Act that sits in the most sensitive category, with full enforcement from 13 May 2027, and any photographer using a tool like this needs to know where they stand.
Two things are structurally in the platform's favour. Registration is opt-in and active — a guest chooses to provide a selfie in exchange for their photographs, which is a materially stronger position than recognising faces of people who never agreed to anything. And event-scoped collections mean a guest's face is only ever compared within the event they attended.
The obligations themselves belong to the operating business, which is the Data Fiduciary under the Act. The platform's job is to make consent, purpose limitation and deletion practical rather than impossible.
The other half: choosing the album
Alongside guest delivery, the platform handles the decision the paying client has to make — which hundred photographs from several thousand go into the printed album.
That decision normally happens over WhatsApp, across the couple, both sets of parents and anyone else with an opinion. Batches of compressed images go out; screenshots, forwarded messages and descriptions like "the one where he's laughing" come back. Different people choose overlapping sets, nobody knows the running total, and the photographer reconciles a chat thread by hand.
Galleries are instead shared as signed, expiring links. No account, no app — the link works, which is the right amount of ceremony for something a mother-in-law will open once on a phone. Each photograph has a selection control, and a running count against the album's limit.
The limit is enforced during selection
An album has a fixed page count, so the cap exists regardless. Enforced while choosing, it is a neutral constraint. Discovered afterwards, it means telling a family to remove ninety favourites.
Everyone sees the same state
Selections are recorded against the gallery, so all stakeholders work on one evolving set rather than parallel private lists.
Progress persists
Choosing from thousands of images is not a single sitting. Selections survive between visits.
Events, galleries and albums
An event holds multiple galleries or albums, each with its own limit, so a wedding's separate functions are selected separately.
One supporting decision worth naming
Neither feature requires full-resolution files in the cloud. Recognition works on proxies, and so does choosing a frame. So originals stay on the photographer's own disk and only low-resolution versions are uploaded.
High-resolution originals
- Never uploaded, never transferred
- No recurring storage cost on files nobody will reopen
- Photographer keeps custody of their own work
- Printing happens from local files as it always did
Low-resolution proxies
- Enough detail for recognition and for judging a frame
- Uploads in minutes rather than hours
- Galleries load quickly on a phone
- Linked by identifier back to the local original
It keeps the subscription affordable for a working photographer, and it means the platform never holds the asset that actually has commercial value.
What the platform covers
Why the stack is split in two
A Laravel application and a serverless Python pipeline, because the two halves have opposite load profiles and putting them on the same infrastructure would waste money on one of them.
AWS Rekognition
Managed face detection, indexing and matching. Training and maintaining our own model would have added significant cost and risk without improving results for this task.
Python on Lambda
Recognition load is violently bursty — thousands of images after an event, then nothing for days. Serverless means the client pays for events processed, not for a server idling between weddings.
Laravel
Photographer panel, admin panel, events, galleries, selection state and subscriptions. Steady predictable load that suits a conventional application server.
Amazon S3
Holds low-resolution proxies only, and issues the signed URLs that make gallery sharing work without accounts.
Signed URLs
Time-limited gallery access without authentication — the right level of security for a link shared inside a family group.
Plan-based event limits
Allowances configured per plan, so the thing that costs money to serve — events processed — is the thing the pricing is built on.
How the team built it
GegoSoft engineers use Claude Code as standard daily tooling. Across a split stack it did most work at the seams — the Laravel side talking to the Python pipeline, Lambda handler structure, S3 and signed URL handling, and tests around selection limits, where an off-by-one means a client selects one photograph too many and the photographer finds out at print time.
Event-scoped face collections, the serverless boundary and keeping originals local were architectural decisions made by the team. Every change passed normal review before merge.
Common questions
Can GegoSoft build face recognition into our product?
Yes. We have built an event-scale face matching pipeline on AWS Rekognition with serverless processing. The useful conversation is usually not whether a managed service can do the task but where it should run and how the biometric data is scoped and retained.
Why use AWS Rekognition rather than training your own model?
For face matching at this scale a managed service is more accurate, cheaper and lower-risk than anything we would train. We recommend a custom model only when a managed service genuinely cannot do the job, which is rarer than it is made to sound.
How is guests' facial data handled?
Registration is opt-in — a guest chooses to provide a selfie in exchange for their photographs. Face indexes are scoped to a single event, so a guest is never matched against another photographer's event. Consent wording and retention are the operating business's obligations as Data Fiduciary under India's DPDP Act.
Why index faces per event instead of globally?
Accuracy improves because the candidate pool is small and contextually related, guests are not searchable across unrelated events, and an event's biometric index can be disposed of as a single unit when it is no longer needed.
Do clients need an account to select photographs?
No. Galleries are shared as signed, expiring links. Requiring accounts from every family member involved in the decision would lose most of them.
Can GegoSoft build an AI SaaS product for us?
Yes. Multi-tenant SaaS with subscription tiers, media handling and AI services is regular work. The architecture conversation before any code is usually where the value is — this product is affordable to run because of decisions about where processing happens and what never gets uploaded.
Related work
Have an AI feature that has to pay for itself?
Tell us what you want recognised, matched or generated, and how often. Whether an AI product works commercially is usually decided by where the processing runs, and that is the first thing we would look at.
Start a conversation See all case studies