TravelPort
A full rebuild of TravelPort’s destination platform on Next.js and Payload CMS — faster pages, structured destinations and packages, and a localized editorial workflow, deployed with Docker and Nginx.
My Role
Tech Lead — led the redesign and rebuild: Next.js architecture, the Payload content model, performance work, localization, and the deployment pipeline.
Project Type
Client Project — rebuilding a travel agency’s destination discovery and package platform for performance and editorial control.
Tools Used
Next.js, React, TypeScript, Payload CMS, Node.js, i18n, image optimization, Docker, Nginx, custom CI/CD
Live Link
https://travelport.ge
Problem & Solutions
Replacing a Legacy Site Without Losing Content
Problem
The old platform mixed destinations, tours, and campaigns in unstructured pages; a rebuild that dropped content or URLs would have cost the search traffic the agency depends on.
Solution
Content was modeled in Payload — destinations, packages, campaigns with relations — migrated, and served under preserved URLs by Next.js. The rebuild was invisible to search engines and obvious to visitors.
Performance as the Product
Problem
Travel browsing is image-heavy and mostly mobile; the legacy stack shipped full-size photos and heavy scripts on every page.
Solution
Next.js server rendering, responsive image optimization, and a strict JavaScript budget cut page weight dramatically and made destination pages load instantly.
An Editorial Workflow in Every Language
Problem
Seasonal offers change often and must ship in several languages at once; waiting on a developer for each change delayed every campaign.
Solution
Payload’s localized fields and a preview-friendly Next.js front end let the agency’s team publish a campaign in all languages themselves, with Docker/Nginx deployments handling releases.
Architecture
Next.js server rendering in front of Payload CMS; editors work in Payload, visitors get optimized pages through Cloudflare and Nginx.
Decision log
The calls that shaped the build — what was decided, why, and what it cost.
Rebuild instead of optimize
Decision. Rebuild the platform on Next.js and Payload CMS rather than patching the legacy site.
Context. The problems were structural — unstructured content and page weight — not cosmetic.
Consequence. Higher upfront effort; a structured content model and fast pages afterwards, with every indexed URL preserved through redirects.
Payload over a bespoke CMS
Decision. Use a code-first CMS instead of writing a custom one.
Context. Editors needed localized, relational content quickly; the agency did not need a novel editor.
Consequence. Localized fields and relations out of the box, and the content model lives in code and version control. Hosting includes a Node process instead of static files only.
Server rendering with per-device images
Decision. Render pages on the server and serve responsive image variants.
Context. Travel browsing is image-heavy and mostly on phones.
Consequence. Destination pages load instantly; the runtime needs a cache strategy and a Node host, handled by the Docker and Nginx pipeline.
Destinations as Structured Content
Every destination is a Payload document with media, packages, and localized copy; Next.js renders the browsing experience from that structure instead of hand-built pages.
Packages and Campaigns Without Rebuilds
Packages and seasonal campaigns are content types with their own fields and relations, so a new season is an editorial task, not a development ticket.
Fast by Architecture
Server rendering, optimized images, and a minimal client bundle turned a slow legacy site into one that loads instantly on mobile.
Growth & Outcome
The rebuilt platform is significantly faster and easier to maintain: destinations, packages, and seasonal campaigns are structured Payload content, pages render through Next.js, and the team publishes in every language without a developer.
Gallery
