Wildkind: Replacing an Expensive Platform, One Piece at a Time
Replaced a platform that fell over at peak, one piece at a time — ending in a 17% revenue lift.
The situation
Wildkind's enrolment platform ran on WordPress — enrolment, booking and marketing pages, all on one system. Enrolment was the real problem: it only opens for a 4-month window before each event, and at peak, demand was enough to bring WordPress down entirely. That's what needed fixing first, not a "let's modernise everything" rebuild.
My role
As Head of Technology, this sat squarely in my remit — architecture choices, hands-on implementation, and the stakeholder communication to go with it. I set the migration sequence, made the architecture calls, and wrote a meaningful share of the implementation myself, including the WordPress-to-Firebase auth bridge that let the cutover run without members noticing.
For the booking rebuild, I co-owned the technology budget with the Head of Product — balancing platform resilience against the growth the business needed — and kept the board and wider team informed as the migration progressed. I still write a lot of code at Wildkind day to day; this wasn't handed off to a team while I managed from a distance.
The approach: enrolment first, invisibly
I moved enrolment onto Next.js and AWS Lambda, which could actually hold up under peak load instead of falling over. Marketing and booking stayed on WordPress in the meantime, so visitors were moving between two completely different front ends without any way to tell.
Underneath that, I migrated every member login from WordPress to Firebase invisibly, then switched WordPress itself to authenticate through Firebase too — so existing members kept working across both systems without noticing a thing.
The approach: booking next, for revenue
Once enrolment was stable, booking was the next priority. Alongside rebuilding the booking system as a whole on Next.js and MedusaJS, I added the ability for members to dynamically add extra credit to their account during the enrolment flow itself — something the old system couldn't do at all.
Marketing pages stayed on WordPress — they work fine as-is, so they weren't worth touching yet.
Outcome
- Enrolment stopped falling over at peak — the exact moment the business could least afford downtime.
- Migration ran invisibly to members: different systems underneath, one seamless login on top, nobody noticed the switch.
- A rebuilt booking system plus a new dynamic extra-credit feature, together driving a 17% uplift in extra-credit purchases.
Facing something similar?
If this looks like a problem you're staring down, I'd be glad to talk it through.