Booking platform & GoCardless integration

A single-page WordPress site paired with a bespoke enrolment plugin, built on standard WordPress patterns — Custom Post Types, REST API, native admin UI — with no third-party plugin dependencies for the core booking logic. Less to maintain, less to break, and full ownership of the source code, database, and credentials in the client's name from day one.

The booking flow itself was deliberately minimal. No login. Honeypot anti-spam. Duplicate-booking prevention via child name, date of birth, and email. An instant confirmation screen with a reference number. When a class fills, a waiting list auto-engages, captures identical data, and auto-promotes the next person in line — emailing them — when a confirmed seat is freed up. The admin can override any of it manually but rarely needs to.

GDPR was built in rather than retrofitted. Versioned consent stored in the database so the client can prove what was agreed and when. Plain-English consent language, not legal boilerplate. Personal data automatically anonymised twelve months after term end. Subject access and erasure requests handled in minutes rather than days. Two-factor authentication on admin accounts, encrypted backups, role-based access.

Mid-engagement, the scope expanded. The original brief explicitly excluded fee collection — the booking was the conversion, and recurring fees lived in a separate workflow. But as the build progressed it became clear that the recurring-fee workflow was the bigger pain point, not a separate concern. I added a GoCardless integration for Direct Debit collection: parents enrol once, set up the mandate at the same time, and term fees collect themselves. The integration sat on top of the existing custom plugin rather than replacing it, which kept the architecture clean and kept the cost-stable promise intact — no SaaS subscriptions tied to enrolment volume, ongoing cost limited to managed hosting and GoCardless's per-transaction fee paid by the client directly.