PicPledge product artwork. The wedding results below describe the actual live event.
The problem
More of the day, from more people.
A wedding has a hundred viewpoints, but the couple only gets to see a few of them. I wanted guests to have one place to contribute their photos and find the moments they cared about, with clear control over who could get in and what happened to their data.
My role
One owner, across the whole product.
I came up with the product, designed the experience, developed the application, and owned delivery.
Responsibility
Product vision · Design · Engineering · Delivery
Platform scope
Responsive web, with shared iOS and Android client code
Current status
Live web product
Product decisions
The choices behind the experience.
What I chose, why it mattered, and what I accepted in return.
01
An invitation gets you into an event; it does not open the album by itself.
I required an account and event membership before someone could see private content. A shared invitation starts that process; it is not a permanent viewing link.
Why I chose it. Event codes get passed around. Hosts need to be able to see who joined, remove someone, and revoke access for that person.
The tradeoff. There is an extra sign-in step for guests. I accepted that friction to make access personal and removable.
How it is delivered
Membership and photo access are checked on the server. Host controls cover invitation rotation, upload closure, and guest removal.
02
Finding your photos should be a choice made inside each event.
I moved facial matching out of account sign-up and into an optional, event-specific experience. Finding yourself and allowing other people to find you are separate permissions.
Why I chose it. Permission given for one wedding should not become permission to recognize someone at every event they attend.
The tradeoff. People opt in again for another event. Matching on their own device also puts some work on that device.
How it is delivered
New events default to optional on-device matching, with matching off as an alternative. Facial data has an event-bound retention window. Turning off Find Me removes the person's facial reference and matches; changing the event's mode clears its facial-matching data.
03
An interrupted batch should leave guests a clear way to finish.
I made uploads show progress and recovery per photo, with duplicate detection and limited simultaneous uploads. Guests can retry the affected items.
Why I chose it. During an event, attention and connectivity are limited. A guest should be able to tell what arrived and what still needs a retry.
The tradeoff. The app limits concurrent uploads rather than sending every file at once.
How it is delivered
Upload completion is verified by the server. Photos pass safety screening before publication; browsing published photos does not wait for facial matching.
04
Deleting an account should have clear consequences for a shared album.
I made account deletion remove the person's profile, uploaded photos, and authored content. A separate upload-removal action lets people take their photos out without deleting their account.
Why I chose it. People need control over what they contributed and a clear explanation of what will disappear. Other participants' uploads remain their own contributions.
The tradeoff. Removing someone's contributions changes a shared album. I accepted that consequence and made it clear before confirmation.
How it is delivered
The deletion flow includes a clear explanation, separate upload removal, and background cleanup of contributed media.
05
Let prospective hosts try the experience before requesting an event.
I built a populated example event with fictional people and sample content. Members can explore the gallery, reactions, chat, and event-admin experience.
Why I chose it. It is easier to understand a shared album by trying one than by reading a feature list.
The tradeoff. The example is temporary and deliberately bounded. It cannot invite other people or change a real event.
How it is delivered
Exploration uses a device-only layer for most interactions. The example expires, and its temporary nature is explained in the interface.
A decision I changed
I moved matching into the event.
My first design put an optional selfie step in account setup and reused that reference across events. It made future matching easier: a person could enroll once and keep going.
I changed that boundary. A choice made for one wedding should not follow someone into every other event. Matching now starts inside the event, and people can use the album without it.
Before
An optional account-setup selfie became a reference that could be reused across events.
After
An optional reference belongs to one event. Find Me and permission for others to find you are separate choices.
The cost I accepted. People opt in again at another event, and on-device matching asks more of the device doing the search. I chose that over carrying permission from one occasion into another.
What changed in the product. Account creation no longer asks for a matching reference. The choice sits beside the event it affects, with its own lifetime and withdrawal controls.
This design evolution is documented in September 2026. The wedding usage figures describe the live event; they do not measure the effect of this change.
Product walkthrough
A shared album, from invitation to keepsake.
PicPledge's product film introduces the experience. The steps below explain the choices behind the flow.
Product film with illustrative imagery. For the full film description, use the link below.
Join the people you are there with
An invitation starts the joining flow. An account and event membership give each guest an identity and access the host can revoke.
Add your perspective
Guests contribute photos to the same private album. Per-photo progress and retry controls help them see what arrived and finish an interrupted upload.
Find the moments you care about
Browse the album, keep favorites, and optionally use Find Me inside that event. Letting other people find you is a separate choice.
Keep a fuller record of the day
Download the photos you want to keep. At my wedding, 40+ simultaneous users shared 100+ photos, giving us perspectives we would otherwise have missed.
I built the application and its supporting tests alongside the product. These figures describe the scale of that work.
131,720
lines of application source 999 source files
174,355
lines of tests and test support 1,069 test/support files
Source snapshot · Oct 19, 2026. Physical lines include comments and blanks. Dependencies, generated native projects, build output, assets, and lockfiles are excluded. Documentation and tooling are separate.
Saved coverage report · Oct 19, 2026
Measure
Coverage
Covered / total
Statements
100%
31,135 / 31,135
Branches
100%
22,578 / 22,578
Functions
100%
7,645 / 7,645
Lines
100%
27,128 / 27,128
Coverage measures the configured executable source, rather than every file in the repository. The report date is separate from the source-size snapshot.
How these figures are measured
Physical lines in committed first-party application source and tests/test support, including comments and blank lines. Excludes dependencies, build output, generated native projects, assets, lockfiles and type declarations. Documentation, tooling and configuration are counted separately and are not included in these source figures.
Saved unit/component coverage reports for the configured executable JavaScript/TypeScript source. Coverage percentages do not apply to every physical line in the repository. CSS, schema/migrations, dependencies, generated output and other uninstrumented files are outside the measured coverage scope.
Shared React screens target web, iOS, and Android through thin client shells.
Private object storage and server-authorized upload and read paths support the album.
Durable background jobs handle slower work, retries, exports, and cleanup.
Staging records include a 300-attendee simulation. That is a load rehearsal, separate from the 40+ people at the wedding.
Results and status
A wedding album with perspectives we would have missed.
At my wedding, 40+ people used PicPledge at the same time and shared 100+ photos live. We got candid moments and angles we would otherwise have missed. That is the outcome I care about: a fuller record of the day, made by the people who were there.
The web product was used live at my wedding. The repository also contains iOS and Android client shells; this case study does not claim store publication or completed native-device validation.
What this work represents
The decisions that matter most to me are often the ones behind the photo grid: who can enter, how a failed upload recovers, what consent means, and what people can remove later. Owning the whole product meant making those choices work together.
PicPledge