posa: forty phones, one set of rules.

The product

A disposable camera on a wedding table works for three reasons: there is little film, so every shot counts; nobody sees anything straight away; and at the end there is a moment when everyone looks at the photos together. posa tries to keep all three on a phone.

The category already exists. POV, Lense, Scene and a dozen clones sell the same model: a QR code, a photo cap, a reveal the next day. Our pitch could not be “a shared disposable camera done well”, because everyone says that. We bet on two things we can prove: the reveal as a ritual, with a time and a name, and a stated expiry, after which the photos are really taken down.

The trouble with rules

In an app like this almost every rule is worth money. Guest seats and shots per guest are what the host paid for. Closing the event and the reveal are the product's promise. These rules have to hold across every guest's phone at once, including phones that are offline, running an older build or closed when the reveal comes. Only one place sees all of them: the server.

The subtle case is the last free seat. Two guests opening the invite at the same moment both read “one seat left” and both get in, unless the count happens on a locked row, inside the same transaction as the join.

A party with no signal

Parties happen in basements, in the countryside, in rooms full of people. A shot must never be lost for lack of network. Every photo goes straight into a queue saved on the phone, which retries with growing waits and starts again when signal comes back or the app returns to the foreground. A shot is refused only when the server says so, for example because the shots have run out.

The server accepts a photo taken before the event ended even if it arrives later, within a grace period, so a guest with no signal can upload it on the way home. The file path is fixed when the shot is taken and the function that records it is idempotent: if the response is lost and the app retries, no second shot is spent. The camera counter shows the server's remaining shots minus those still queued, so it never promises film already used.

Photo size was a cost decision too. Every shot is uploaded twice: the original, scaled to 2560 pixels on the phone, and a 1280-pixel copy for the grid and the viewer. A file is written once but read every time any guest opens the roll, and serving everyone a 3 MB original would have set the product's margin.

Privacy as a product feature

A disposable camera at a party frames people who agreed to nothing. So consent is a row in the database, with the version of the text that was shown. It is not decoration: without that row the functions that record photos and voice messages refuse the request, and the storage policy does not even let the file in.

The reveal is a promise too. Until the roll develops, photos stay veiled. Voice messages cannot be blurred, so for them the server itself refuses to hand over the file until the moment comes.

Expiry applies to the file, not the memory. The roll still says who was there and how many shots they took, with empty frames where the prints were. The host gets a warning seven days before, and an hourly job deletes the files first and marks the rows second, so a failure halfway through fixes itself on the next run. Account deletion is also a recorded request that outlives the user and is retried up to five times if it does not complete straight away.

The one principle we were not keeping

The first principle written in the product documentation was that a guest should not have to install anything to take part. For the first days it was false: the camera needed the app. It is the detail that decides whether a roll has twelve photos or forty, because many guests will not download an app for one evening.

I built the whole web side. The invite now opens in the browser, with a web camera that goes through the same database functions and so obeys the same limits. If the guest decides to install the app, a one-time code moves their shots into it, with nothing lost. The same site hosts the landing page, the privacy and support pages and the account deletion request.

What we took out

Assigned scenes were the strongest point of our strategy: instead of forty photos of the cake, each guest got shots to fill. I had added them, and I removed them five days later.

They turned the camera into homework. They also had a bug: with an instant reveal, some guests could not take their shots at all. The migration that removes them still accepts the argument from builds already installed and ignores it, because no phone out there should break over a product decision.