The result in one sentence
Event photographers who delivered photos through loose links and negotiated sales by message now have their own gallery where buyers pick their photos and close the order on WhatsApp, and the platform became a product that spins up for a new photographer in under an hour.
- Client: Flash Arena, a gallery and sales platform for event photographers' photos and videos
- My role: development, Supabase architecture and turning the project into a product replicable per client
- Timeline: first instance replicated for a new client in May 2026
- Key result: a new client goes live with database, storage, functions and starter content in 45 to 60 minutes, following a playbook
- Sell on the channel buyers already use: instead of a payment gateway checkout, the order is assembled in the gallery and sent, formatted, to the photographer's WhatsApp, where the negotiation already happened.
- Do not lose the ones who walked away: if a buyer filled in name and WhatsApp and has selected items, the selection is recorded as an abandoned cart so the photographer can follow up.
- One instance per client, no rework: I inventoried the entire original project (tables, functions, triggers, policies, bucket, edge functions) and turned it into reproducible migrations and a step-by-step playbook, tested by bringing up a real client from scratch.
- Photo orders closed straight on the photographer's WhatsApp, already organized by event and folder
- Abandoned carts recorded so the photographer can recover sales
- Large file uploads without losing progress
- A new client live in 45 to 60 minutes, following a playbook tested in production
The context
Event photography lives on volume: hundreds of participants, thousands of photos a day and sales happening while the moment is still fresh. Buyers want to find their own photos fast, on their phones, and sellers want to receive the order without spreadsheets or endless back-and-forth.
The problem
Photos lived in generic storage links, buyers had to describe which ones they wanted by message and many orders died halfway without the photographer ever knowing. On the technical side, the first version worked for a single client: onboarding another photographer meant rebuilding database, permissions, storage and functions by hand, with the risk of missing a piece.
The approach
The solution
Public gallery. A home page with content editable by the admin, events filterable by year, semester and search, and each event organized in folders, with progressive loading so it works well on phones.
Selection and order via WhatsApp. Buyers mark photos and videos, fill in name, email and WhatsApp with validation, and send a message already organized by event and folder, listing the chosen files.
Photographer dashboard. Management of events, folders and media, resumable uploads of large files, automatic thumbnails for photos and videos, editing of site copy and images, and tracking of abandoned carts.
Under the hood
React 18 with TypeScript, Vite, Tailwind and shadcn/ui on the front; Supabase with Postgres, RLS, Auth, Storage and edge functions for thumbnails and media maintenance. Uploads use the resumable TUS protocol, for files up to 1.2 GB without losing progress when the connection drops. Photo and video counts per event and folder come from a single query or RPC, avoiding N+1. Deployment runs in a container with Nginx. During replication, I closed gaps between the original project and the repository (unapplied migrations, a missing RLS policy on folders) before applying to the new client, and the whole process is documented end to end with a checklist and smoke test.
Results
What I take from this project
What separates a project from a product is being able to do it again. Inventorying everything the system actually has and turning it into migrations and a checklist was less glamorous than building screens, and it is what made the business scalable.
