Everything that isactually shipped.

• →The capture app opens a transfer session bound to one event folder and shows you the address and credentials to enter on the camera.
• →Cameras that can transfer over a network send frames straight to the machine running the app.
• →The connect flow walks through network setup, credentials and a test shot — so you find out it works before the ceremony, not during it.
• →Files are processed and uploaded as they land. The upload is the import.
• →One capture session runs at a time, which is what stops the reception ending up in the previous event’s folder.

• →One QR code per event. Scanning it opens the event page on your studio’s own path.
• →Everything the guest touches runs in the phone browser they already have open.
• →Camera permission is requested in the page; the guest takes a single selfie and that is the entire ask.
• →Returning guests continue with the face already on file instead of taking another selfie.
• →Guests who arrive before the photos do can ask to be told when their set exists.

• →The browser captures one JPEG and posts it to our API. That is the browser’s entire role.
• →Our face service computes a 512-dimension AuraFace embedding on the server.
• →The embedding is stored as a vector against that guest’s record.
• →Gallery photos are embedded the same way as they are ingested, whether they came from the web or from the capture app.
• →Matching is a cosine nearest-neighbour search across the event’s faces, with a distance cutoff we tune.

• →Shots organise into folders; the client sees them as tabs rather than one infinite grid.
• →Clients and crew are added to an event by phone number, with host or editor rights.
• →You can cap how many photos a client may select, so the album package enforces itself.
• →Comments attach to individual photos rather than to the event, so feedback arrives on the frame it is about.
• →A review screen shows the selected set on its own before it goes to the edit.

• →Every studio has its own path segment; events and galleries live underneath it, so the link a guest opens reads as yours.
• →Your studio name and brand assets carry onto the event page and the galleries a guest lands on.
• →The same routing serves the guest gallery, the selection link and the studio wall.

• →The wall has its own slug and its own address, so you can open it on whatever drives the screen and walk away.
• →It stays dark until you publish it, and you choose which of the event’s folders appear on it.
• →It runs in a browser, so there is no second install to do at the venue.

• →Published on Google Play as com.dfeverx.studioshare.
• →It is the studio-side app: events, folders, galleries and invites from a phone.
• →Guests never needed an app in the first place — their side has always been the browser.

Guest Graph consent capture

A separate, explicit, easy-to-decline opt-in that lets a guest hear from you later — kept legally distinct from the consent that powers "find my photos".

Earned Impressions tracking

Measure how often guests reshare your branded work, so reach stops being a guess.

Guest-to-Lead dashboard

Your G2L rate per event: how many guests arrived, how many opted in, how many became real enquiries.

Second-order booking attribution

Trace a signed booking back to the event where that client first showed up as somebody else’s guest.

macOS and iOS apps

Android is live on Google Play and the desktop capture app runs on Windows. macOS and iOS are still in development.