It's a camera
No file picker, no gallery import, no drag-and-drop. Live capture only. A guest cannot dump their camera roll into your event.
One photographer can only stand in one place. Crowdtography hands a disposable camera to everyone already sitting in the seats you can't reach — and every shot lands in your folder, with your brand on it.
The whole loop
The codes go where a photographer physically cannot be — odd angles, back rows, the moment happening at the other end of the room. That reach is the product.
What it refuses to be
Most of what makes this work is what it will not do. These are hard rules in the build spec, not preferences.
No file picker, no gallery import, no drag-and-drop. Live capture only. A guest cannot dump their camera roll into your event.
The count decrements on the server, atomically. Discarding a shot does not refund it — the same discipline a disposable camera enforces.
The watermark leads with the organizer's brand. Crowdtography is the secondary badge, never the headline.
Google OAuth uses drive.file and nothing broader — access to the files it creates, not to a customer's Drive.
Uploads go straight to object storage with presigned URLs. The application server never handles the image data.
No editing, no social layer, no billing in the first version. It captures and delivers; everything else is a later argument.
Why it works
A hired photographer produces better individual frames. They cannot produce the frame from the third row, at the exact second it happened, from the angle only the person sitting there had. Fifty phones already in the room can.
The shot limit is what keeps that from becoming noise. A guest with five shots takes five deliberate photographs. A guest with unlimited shots hands you four hundred near-identical ones and a sorting problem.
“The differentiator is reach. Codes go at angles, seats, and moments no single photographer can physically cover.”
Crowdtography build spec
Under it
drive.file scope