Self-Serve Fair Sites.
When BMI Global Ed's fair websites were coded by hand, changing one word in a paragraph could break the registration form students sign up through, and every change waited days for a designer. I rebuilt them as one platform on WordPress. Buy vs build had no single answer: open source for the editing, licensed plugins for fields and translation, and custom code only where our fairs needed something no one sells. Event teams now publish their own changes in minutes.
Every word change was a code change
BMI Global Ed runs education fairs where universities meet students who want to study abroad. Every fair needs its own site, in its own language, with its own dates, venues and universities. Designers coded each site by hand, with the page's text in the same file as its registration form, so every edit to the words was an edit to the code.
Buy vs build, or open source? All three.
Every part of the platform went through the same question: is this a solved problem we can adopt or license, or is it specific to our fairs?
WordPress Multisite
Editing, users, roles and publishing, and one network running many sites. Solved problems, so there was nothing to build.
Licensed plugins
Custom fields, translation and a page builder, each cheaper to license than to build.
What no one sells
The fair configuration, the link to BMI's own event and registration system, and each market's own tracking.
Our own theme
We started on a bought theme too. Within months I moved us to our own, for control over the markup and how pages load, and kept the bought page builder on top.
Spend engineering only where nothing off the shelf fits.
What differs between fairs is data, not code
One shared theme serves every fair site. Everything that makes a site that fair's own is data the event team sets in WordPress, so a new site is configuration, not a build.
Five configuration screens
Event Details, Analytics & SEO, Design, Footer and Sponsors: a whole fair site set up without a developer.
Live dropdowns
Editors pick a real fair and city from BMI's own event system instead of typing an ID. The event system stays the source of truth.
Cities as content
One template serves every city, generated from data, instead of a copied page for each one.
A library of sections
22 reusable page sections and 4 hero variants that editors assemble into pages, so page structure is content too.
Per-language settings
Each language carries its own event details, tracking and sponsors, right-to-left Arabic included, with a guard that stops an editor changing the wrong language's settings.
One registration path
Every form posts to the central API, which checks for duplicate emails and serves the exhibitor directory.
Tracking, wired under consent
The layer I coded myself. Each market runs its own tracking set-up, and no tag fires before the student consents.
Attribution across domains
A student can start on a fair site and finish on a third-party virtual-fair platform. Cross-domain linking and a UTM cookie keep that journey one funnel.
Consent in one change
I reworked the entire tracker stack so every tag loads under GDPR consent control instead of firing unconditionally.
GA4 behind Tag Manager
Migrated conversion tracking from Universal Analytics to GA4, with delivery consolidated behind Google Tag Manager.
What marketing does with this data: International Fair Marketing Platform.
From hand-coded pages to a headless front end
Over a decade the fair sites moved through five generations. Since the move to WordPress, every one of them has kept event teams editing their own sites.
- 1
Hand-coded
Designers coded each fair site by hand. Every change meant editing the page file.
- 2
Shared PHP platform
I started one registration engine and exhibitor API for every country. Pages were still edited in code.
- 3
WordPress
Buy vs build, settled. Event teams edit their own sites through configuration screens.
- 4
Rebuilt theme
The offshore team I directed rebuilt the theme into reusable sections, easier to extend.
- 5
Headless front end
A Next.js front end takes over rendering. Event teams still edit in WordPress, and content reaches the new sites through the central API.
Chose the approach, coded the configuration and measurement
I made the buy vs build call and directed the offshore team, never more than five people, that built and maintains the platform. The configuration fields and the measurement layer are my own code; the wider architecture and the later rebuild were delivered by the team I directed.
- Chose to rebuild the fair sites on WordPress, combining open source, licensed plugins and custom code, and moved the platform off its bought theme onto our own.
- Directed the offshore team that built and maintains it, day to day, through written specifications and wireframes.
- Built the configuration fields and live dropdowns, fed from the central API, that let event teams launch a branded fair site without a developer.
- Replaced a hand-maintained city page with one generated from data, and made cities content so one template serves them all.
- Integrated the fair sites with the central platform API for registration, duplicate-email detection and exhibitor directories, across two API generations.
- Coded the conversion-measurement layer across GA4, Google Ads, Tag Manager, Facebook and TikTok, and put every tag under GDPR consent control in one change.
- Directed the rebuild of the theme into reusable sections, delivered by the team, which left the codebase easier to extend.
Tech stack
Say hello.
Message sent.
Thanks for getting in touch.