Saskia Teichmann
Before the first runner crosses the finish line at the Lüneburg City Run on August 30, 2026, the system will have already made many decisions: the appropriate race, the current rate, the age group, team assignment, ticket, and race number.
Registration is more than just a form
On lueneburger-stadtlauf.de Participants select a race and purchase the appropriate ticket. Behind the scenes, this process goes much further. WooCommerce must offer the correct pricing plan at the right time, process the required information for each person, and transfer the data to the ticketing system in such a way that the race number and any subsequent corrections match up.
The project-specific custom code for this is version-controlled in the private project repository. My technical responsibilities include these WordPress and WooCommerce components. This is more specific and verifiable than the blanket statement that I would manage „everything“ related to the event.
Five races, different rules
The program consists of five races: 500 meters, 1 kilometer, 2 kilometers, 5 kilometers, and 10 kilometers. The products share the same registration process but do not have the same age groups, rates, or participant pools.
In the custom plugin, these rules are not copied as text in five different places. Age ranges, pricing tiers, and available variants are handled through shared settings and classes. This reduces the risk that a visible price will differ from what is shown at checkout, or that an age prompt will no longer match the actual validation criteria.
Team Assignment Without Data Proliferation
Participants can assign themselves to clubs, running groups, or school teams. There is also a link to corporate run data. A simple text field isn’t enough for this: The system must suggest known teams, handle missing entries properly, and catch conflicting information during checkout.
The connection to the company run data source has been intentionally minimized. The documented export provides only the fields and technical indexes required by the City Run checkout—no team captain emails, names, dates of birth, or bib numbers. This ensures that an interface isn’t made „practical“ simply by transferring everything as a precaution.
Tickets must remain editable
Once the purchase is complete, the operational work begins. Typos are corrected; participants may switch races; tickets must be reassigned to a different order or reissued. Throughout this process, race numbers, fees, ticket information, and check-in status must remain consistent.
The project plugin includes a shared ticket core, admin tools, and cautious CLI commands with preview and execution limits. The code can back up ticket data, process rebookings in a traceable manner, and preserve existing check-in statuses during corrections. This does not replace the actual check-in product. It ensures that project-specific changes do not silently corrupt its data.
As evidenced by 1,225 registrations
On August 18, 2026 the public live counter showed 1,225 registrations. This is a specific as-of date from the current registration system. Because the counter continues to run, the date is an essential part of this information.
The figure shows that pre-event registration is actually being used. It does not yet indicate how many people will participate on the day of the event, how the check-in process is going, or how participants are experiencing the event. These details can only be verified after August 30.
The outcome remains uncertain ahead of the event
This project report deliberately ends before the finish line. It documents the scope of the system in the repository, the five runs offered, and the public registration status as of the cutoff date. What has not yet been documented is how the event day itself will unfold. Even before the event, the repository demonstrates just how much event engineering goes into pricing logic, ticket corrections, team assignments, and secure work tools.
When registration, rates, tickets, and operations become a business-critical system, I organize the dependencies in the technical consulting together with your team.
Sources
- Lüneburg City Run — Date, Races, and Live Counter
- Versioned private project repository with custom code to ensure consistency across rates, teams, tickets, and check-ins
