TOCA Social Website

The TOCA Social Website was the central place to book online for TOCA Social. If you wanted to make a booking as a member of the public, this was your main interface. TOCA Social offers sports entertainment: you book a slot to use custom hardware where a football acts as the controller. The site was built to support the launch and drive bookings. There was no website before this existed.

As Fullstack Developer, I built the entire initial version. That included the XState booking flow state machine, Stripe payment integration with promo codes, Storyblok CMS integration, and the orchestration of multiple backend services (booking, packages, session, payment APIs). The booking journey involved session recovery, API health checks, form handling for date and time selection, and optional post-booking upsell. XState gave us testable state transitions and session persistence with recovery.

Once I became manager of the information systems team, I shifted to a Project Manager role. I orchestrated tasks and updates through the team, so they handled the development work. Having built the original version, I could suggest optimisations. A lot of the focus went towards marketing updates: positioning deals and events in more prominent places whilst staying informational for the end user.

The thing I'm most proud of is how this fitted into a suite of tools. The website linked to a booking system I had built before, which was controlled by the Schedule Management System. After you made a booking on the website, everything synced to the Reception Desk software. These all worked together without problems for a long time.

Architecture

Gatsby generated marketing pages statically at build time. The booking flow ran as a client-side application with real-time API interaction. The stack was serverless on AWS: Route 53 for DNS, API Gateway and Lambda for backend services, S3 for static file hosting. Deployment happened via AWS Amplify. Routing everything together with serverless was a learning curve at the time, but a good opportunity to learn more about AWS and its internal services.

Observability

Google Tag Manager handled events, funnels, and reporting that fed into SEO improvements. Google Analytics tracked usage. Lighthouse measured page speed over time. CloudWatch and Pingdom monitored URLs and health. That monitoring gave us high uptime.

Testing

There were no integration or E2E tests. A lot of the testing was manual QA. We did have unit tests with Jest: some for specific utilities, but the key ones were for the XState state machine. Those tests verified the booking journey was always valid. Running them gave peace of mind that the booking system had no issues. They were watertight.

CI/CD

There was no formal CI/CD pipeline. Deployments went up via AWS Amplify.

Security

Stripe was the main payment terminal for making bookings. We used it for promo codes too. Data handling followed normal GDPR considerations.

Accessibility

The site was built to WCAG 2.1.

Outcome

I don't have numbers from back then. What I do know: it was rare to hear of any issues with the website. With the monitoring we had, uptime was high. We were never in a position where we had to refund someone due to an error. Over time we made the booking process easier and easier using the tracking data, and that fed into a better outcome.