Multi-country travel and booking platform
Kingdom Market
A multi-vendor travel platform serving 13 countries. I build product features across the stack and own the hotel data pipelines and front-end performance work.
- Ownership
- Employer work, team project
- Organisation
- GCB Holding, team project
- My role
- Full-stack engineer (Dec 2025 – present, remote)
- Status
- In production, ongoing
- TypeScript
- React
- Next.js
- REST APIs
- Python
- Selenium
- BeautifulSoup
Google PageSpeed58 before, 95+ after
Technical SEO60 before, 95+ after
Overview
Kingdom Market is a multi-vendor travel platform that lets travellers search and book across 13 countries. Its value depends on two things the user never sees directly: how complete the listing data is, and how quickly pages load on the networks travellers actually use.
I joined as a full-stack engineer working remotely with the team in Morocco, shipping features across the stack and taking ownership of the listing data pipelines and front-end performance.
Role and ownership
What I personally did
- Shipped 20+ production features across React, Next.js, TypeScript, and REST API integrations.
- Wrote Python extraction pipelines (Selenium, BeautifulSoup) that collect hotel, room, pricing, image, and location data into the listing layer.
- Led the performance work on key landing pages: code splitting, image optimisation, and render-path changes.
- Raised technical SEO health across key landing pages.
Team context. Kingdom Market is built by a team. The work listed here is my individual contribution; product direction and other parts of the system belong to colleagues.
Constraints
- Existing codebase and team conventions; changes had to land incrementally without pausing feature work.
- Listing data comes from many external sources with inconsistent structure.
- Search visibility matters for a booking product, so performance and crawlability are business requirements, not polish.
Solution
Listing data flows in through Python pipelines that extract hotel, room, pricing, image, and location fields and normalise them before they reach the platform's listing layer. Keeping extraction outside the web application means a slow or failing source never affects page requests.
On the front end, the performance work focused on the critical render path of landing pages: splitting code that was not needed for first paint, serving correctly sized modern image formats, and removing render-blocking work.
Sources
External travel listings
Hotels, rooms, prices, images
Extraction
Python pipelines
Selenium, BeautifulSoup, normalisation
Platform
Listing data layer
Owned by the wider team
Web
Next.js front end
Search, listings, landing pages
Key decisions
Extraction as a separate pipeline
Source sites are slow, change structure without notice, and sometimes require a real browser to render.
- Considered
- Fetch and parse listing data inside the web application's request cycle.
- Chose
- Run extraction as standalone Python jobs using Selenium where a browser is required and BeautifulSoup where static HTML is enough, and write normalised records to the listing layer.
- Trade-off
- A second language and runtime to maintain, and data is only as fresh as the last run. In exchange, a broken source cannot slow down or break a user's page.
Fix the render path before adding caching
Landing pages scored 58 on PageSpeed, which hurts both ranking and conversion.
- Considered
- Put more caching in front of the pages and leave the page structure as it was.
- Chose
- Reduce what the browser must download and execute before first paint: code splitting, image optimisation, and removal of render-blocking work.
- Trade-off
- Touches more components and needs care to avoid regressions, but the gains apply on every visit, including first visits that caching cannot help.
Outcome
58 → 95+
Google PageSpeed score
Key landing pages, Google PageSpeed Insights lab score before and after the optimisation work.
60 → 95+
Technical SEO score
Key landing pages, audit score before and after the SEO work.
20+
Production features shipped
Features I delivered personally since December 2025.
Reflection
Lab scores are a starting signal. The next step is to track field Core Web Vitals once enough real-user data exists, rather than treating a single Lighthouse run as proof.
Notes and further reading
Screenshots show public-facing pages only. Internal architecture and source code are not shown, and the diagram is simplified to the parts of the system I worked on.