The Platform Estate.
The technical view of the fourteen systems behind 60–80 international student recruitment fairs a year: how they fit around one central API, how a student’s data moves through them, and the decisions and trade-offs that shaped them.
Everything a fair needs, from stand booking to lead report
Each fair has two sets of users: students, who register to attend, and institutions, who book a stand to meet them. Every job below is done by a system in the estate, and each card links to the case study that covers it.
01BEFORE THE FAIR
Sell the stands
Institutions find fairs by region and audience, plan around the schedule and book online.
Run the exhibitor side
Stand, hotel and travel bookings, compliance documents, printing, shipping and live payments for every exhibiting institution.
Sign up students
Fair websites for every event, country and language register students through the central API.
Reach students between fairs
A student hub for webinars and fair listings, and a study-abroad magazine where institutions sponsor articles.
02ON THE DAY
Check students in
Staff scan a student’s barcode at the door, and a thermal printer produces their badge.
Capture leads
Exhibitor staff scan students’ badges in an offline-first mobile app, rating each lead as they scan it.
03AFTER THE FAIR
Deliver the leads
Each exhibitor receives its leads as a spreadsheet, matched against the students’ registrations, repeat scans removed.
Report across fairs
Per-fair reports, demographic breakdowns and marketing lists for staff and executives.
Turn the data into insightPROTOTYPE
A dashboard proposed as an addition to the exhibitor platform, turning registration and scan data into insight for exhibitors.
UNDERNEATH EVERY STAGE
The central API
One Node.js platform every system above reads and writes through.
Specification and QA governance
A repository of specifications and tests, kept apart from the code it checks.
The legacy fairs platformRETIRED
The original PHP backend and API. Systems moved off it one at a time, and it was retired once the last had gone.
Follow one student through the system
The quickest way to see why fourteen systems are really one: follow a single registration from sign-up to an exhibitor’s lead report. Five systems handle it along the way, and every one of them reads or writes through the same central API.
What shaped the estate
Six things shaped the estate. Each card gives the reason for it and, where it had one, what it cost.
One shared API, not a backend per product
Every product reads and writes through one central API instead of keeping its own backend and copy of the data. It has a module per product domain, so a team of at most five engineers governs one integration boundary, and the modules keep the option to split it later. The cost: one deployable to protect, so every change passes blocking checks first.
Migrate one system at a time
Systems moved off the legacy PHP API one at a time while it kept serving the rest, with no single cut-over day. Its leftover scripts and webhooks went into one catch-all module on the new API before it retired. The cost: two APIs running side by side for three years.
Specifications that mirror the code
A separate repository holds 96 specifications in seven directories, one for each API module, and syncs specifications and test cases both ways with the code, so requirements, tests and code cannot silently drift apart.
Standards held by tooling, not policy
On the systems built once the capability existed, merge-blocking security analysis on the central API, an architecture validator on the exhibitor platform and a three-tier release pipeline hold the standard, instead of a written rule a distributed team might not follow.
Offline-first on the fair floor
Each badge carries an encoded copy of the student’s profile, so the lead-capture app decodes it on the phone with no network lookup, and scanning never waits on the venue’s connection. Leads upload in batches afterwards. The cost: the app and the server that encodes the badge have to agree on its format.
One place to report from
Siloed operational systems were brought together behind one central reporting hub and one central student hub, so reports across every fair come from one place rather than from each system separately.
Cheaper to run, quicker to fix, ready to move
What the architecture delivered in production: lower AWS cost, failures found and fixed faster, a legacy API retired without a risky cut-over, and a platform that could take fairs online in two months.
AWS cost cut by half
The estate runs on AWS: EC2, RDS and S3, deployed through CodeBuild and CodeDeploy. I hired the organisation’s first infrastructure architect and DevOps specialist, who designed that infrastructure, and directed the cloud-management and architectural changes that cut its cost by 50%.
Failures fixed in hours, not days
The core systems now report errors and traces from front end to back end, gated by environment, with alerting. Production failures show up before users report them, and the time to resolve one fell from days to hours.
A legacy API retired without a big-bang switch
The fair registration sites and the reporting hub moved onto the central API in 2024, and door check-in in 2026; the newer fair websites were built on it from the start. The legacy PHP API kept serving throughout, then was decommissioned.
Ready when the venues closed
When COVID stopped physical fairs, registration data, lead exports and APIs were already digital, so going online meant connecting a new front end. Webhooks sent registrations out to an online-fair platform and brought each exhibitor’s leads back in the same format as a physical fair. Two months from choosing the platform to the first live online fair.
What I led
I set the technical direction and the order of work. A small outsourced engineering team built most of the systems from my written specifications and wireframes; the earliest I built myself, as their case studies show.
- Set technical direction for a 14-system, 23-repository estate serving 60–80 international recruitment fairs a year across 18 countries.
- Planned and sequenced the three-year migration off a legacy PHP API onto the central Node.js platform, keeping the legacy API in production throughout, then decommissioning it.
- Directed one API platform organised into six product-domain modules and one catch-all, paired with a specification repository whose seven directories mirror them one for one, with 96 specifications and one QA traceability chain.
- Applied modern engineering governance (merge-blocking security analysis, spec-to-test traceability and a three-tier release pipeline) to the systems built once that capability existed, while legacy systems were held stable and aged out.
- Took the estate to environment-gated, full-stack observability with alerting, cutting time to resolution from days to hours.
- Hired the organisation’s first infrastructure architect and DevOps specialist, and directed the cloud-management and architectural changes that cut AWS infrastructure cost by 50%.
- Own access and repository governance across the 23-repository GitHub organisation, administering access for a distributed vendor engineering team.
Tech stack, by layer
Say hello.
Message sent.
Thanks for getting in touch.