Table of contents
The Challenge
The project began with a requirement that looked simple: create one registration form for a multi-day annual meeting. In practice, every participant belonged to a different combination of committees, boards and working groups, so a standard public form would have created confusion.
The platform also needed to collect accommodation requests, enforce room availability, provide administrators with a clear overview and produce reliable exports for operational follow-up.
Translating Requirements into a Workflow
Each invited participant needed a personalised link. After opening it, the participant should see only the meetings relevant to their roles, together with optional receptions and accommodation choices.
Administrators needed to import the participant list, search and filter registrations, review selected meetings, track submission status and export structured data without manually combining spreadsheets.
A Lightweight Architecture
I chose a lightweight PHP and JavaScript architecture hosted on an existing web server. The application was deliberately kept small, transparent and easy to back up.
The participant data, group assignments, schedule definitions and responses were separated so that the meeting programme could be adjusted without rewriting the registration logic. This also reduced the risk of inconsistent data across the form and admin view.
Personalised Invitation Links
The system generated a unique invitation link for every participant. The link identified the correct record and loaded the participant’s name, group memberships and eligible meetings.
This approach removed the need for users to create accounts while still delivering a personalised experience. It also made invitation emails easier to prepare because every recipient received one direct link to the exact form they needed.
Dynamic Meeting Logic
Participants could belong to several groups at the same time. The form therefore calculated the union of all relevant meetings and prevented duplicate entries when multiple roles pointed to the same session.
Checkboxes, labels, chairs, dates and times were generated from the schedule configuration. Operational changes could be reflected centrally rather than edited across hundreds of individual forms.
Accommodation Inventory and Availability
Accommodation added another layer of logic. Single and twin rooms had separate capacities, pricing and availability. The number shown to users needed to reflect submitted requests and eventually display a sold-out state.
The system reserved a small internal allocation, prevented overbooking and kept accommodation data connected to the participant record. This made the later payment and room-allocation workflow much easier to manage.
Administration and Exports
The administration interface focused on operational clarity. It displayed the participant, email address, groups, registration status, selected meetings and accommodation request, with search, filtering and predictable sorting.
Exports transformed the responses into meeting columns and accommodation fields that could be used directly by colleagues and local organisers. Designing the export format early saved significant manual work later.
Security and Deployment
The application was deployed behind HTTPS with restricted administrator access. Inputs were validated, invitation tokens were non-sequential and operational files were kept outside public browsing wherever possible.
Because the platform ran on existing infrastructure, deployment also included DNS, reverse proxy and certificate configuration. The result was a dedicated branded address without introducing another external software subscription.
Lessons Learned
The most important lesson was to model the operational process before building the interface. Accommodation limits, group overlaps and export requirements influenced the data model far more than the visual form.
A custom application was justified because the workflow was highly specific. The value came from removing repetitive administrative work and presenting each participant with only the information that mattered to them.
Final Thoughts
This project shows how a focused web application can replace a complicated combination of generic forms, spreadsheets and manual email follow-up.
The platform remained intentionally small, but it solved a real operational problem through personalisation, clear data structures and a practical administration workflow.