Event Media Automation

The Brief

An event media company photographs and films dance competitions, then sells prints and digital media to parents on the day. At the time this project started, the workflow was largely manual. Photographers shot dancers on stage, editors resized and watermarked the photos afterwards, staff searched through folders to find a specific dancer’s images when parents asked, and prints were queued to a printer one by one. Video was worse. Parents often waited a day or more for their media, sometimes longer for the bigger events.

The brief was to eliminate the manual pipeline. Photos and videos should be captured, processed, indexed, sold, delivered, and printed with almost no human intervention, fast enough that a parent could walk from watching their child on stage to holding a finished print in the foyer.

The Challenge

Three things had to be true, and none of them are trivial.

First, throughput. A busy competition day produces 6,000 to 10,000 photos across dozens of dance items, with new material arriving every few minutes as each dance ends. The system had to keep up in real time, without a growing backlog through the day.

Second, indexing. Parents do not want to scroll through thousands of photos. They want to type their child’s name and see only their child’s media. That means every photo has to be associated with the correct dancer at the moment it is taken, on a live event floor where there is no time to tag things after the fact.

Third, delivery. Once a parent paid, the correct media needed to reach them immediately: printed on site, or emailed as digital downloads, or both. Any manual step in that chain would create a queue, and queues at events become complaints.

The Approach

The system runs on an offline server on site at each event. This was a deliberate choice. Event venues frequently have unreliable or no internet, and any workflow that depends on a live connection during a competition is a workflow that will fail at the worst possible moment. Media is captured, processed, and sold entirely locally, then synced to an online server in the background whenever a connection is available.

The tagging problem was solved at the point of capture. Photographers use physical numbered buttons corresponding to each dancer. When a dance ends, the photographer presses that dancer’s button, and the server automatically associates the last batch of photos with the right person and starts processing. There is no separate tagging step and no way for photos to be misfiled at scale, because the tag is applied in the same moment the shooting stops.

Everything downstream, from resizing and watermarking through to printing and emailing, runs as automated server jobs. Human staff exist mostly to take payments and hand physical prints to the parent picking them up.

The Build

The platform is built in PHP on CodeIgniter, with jQuery and AJAX on the frontend, MySQL for data, and Linux underneath. It runs as an on-site offline server at each event, with an online counterpart for remote sales.

The end-to-end pipeline covers capture through delivery. When a dance ends and the photographer presses that dancer’s button, the server ingests the batch, resizes and watermarks every image, files it under the correct dancer, and makes it available for viewing and sale within 20 to 30 seconds. Parents browse and buy on six foyer-based viewing stations by typing their child’s name, which surfaces only that child’s media across every dance she has performed in that event.

Payment flows are integrated into the same system. A digital purchase triggers an automated email delivering the files. A print purchase triggers the print queue directly at the machine, so the print is ready by the time the parent walks to collect it. Video works the same way, with the server automatically topping and tailing purchased videos with intro and outro sequences before sending.

The online side runs the same catalogue for remote sales. Parents who could not attend can buy the same media from home, with the same automated delivery on payment.

The system also produces analytics for event organisers, covering sales patterns, popular items, and revenue breakdowns, so competitions can understand where their money is actually coming from.

Key Technical Decisions

A few decisions were structural to the whole platform working the way it does.

Offline-first architecture with background sync. Trusting the venue’s internet to handle live sales would have been a disaster. Every event runs from a local server that does not need external connectivity to function. The online catalogue receives media by background upload whenever a connection is available, which is invisible to both staff and customers on the day.

Tagging at the moment of capture. The physical numbered button per dancer is the whole reason parents can find their media by name within seconds of the dance ending. It moves the tagging effort from a post-processing step (which does not scale) to a zero-effort action the photographer already needed to perform anyway.

Server-driven print and email delivery. Once payment is confirmed, the server handles fulfilment without a human touching a file. Digital orders are emailed automatically. Print orders go straight to the printer and come out ready to collect. This kept staff freed up for the parts that actually need a person.

Video intros and outros applied server-side on demand. Rather than pre-rendering every video with branding (impossible at the volumes involved), the server assembles the final video only at the moment of purchase. Same principle as the photos, applied to a slower medium.

The Result

The platform ran the entire operational workflow of the company for years, at both the small end (local South African competitions with 100 to 200 sales) and the large end (multi-week events with over 2,000 sales through the venue plus additional online sales afterwards). It handled 6,000 to 10,000 photos per event day at 20 to 30 seconds per dance item, sustained across full competition days without falling behind.

It ran the world finals of a major international dance competition every year for several years, including two or three of that competition’s international qualifiers, in venues across South Africa, the UK, Croatia, Portugal, Prague, and Spain. Domestically it powered around ten dance competitions a year.

The commercial impact was straightforward. The company had a genuine speed advantage no manual competitor could match, and won contracts on that basis. The international organisers of the sport’s largest event kept booking them for the finals because no other media company could deliver the same experience at the same tempo.

Built solo over roughly six months to first production use, then iterated on live over seven years. By the time I left the company, around 90% of the end-to-end workflow ran without human involvement.