Paglipat

A flight metasearch platform that lets travelers compare and book flights across hundreds of airlines and travel agencies in a single search. The name “Paglipat” comes from Tagalog, meaning “to transfer” or “to move,” reflecting the essence of travel.

Originally built on Next.js, Paglipat was rebuilt from the ground up as a static-first, edge-optimized site: faster to load, cheaper to run, and indexable in 11 languages worldwide. Instead of rendering pages on demand behind a server, I precompute them at build time and serve them from the edge, so the first paint does not wait on a runtime. The metasearch itself still queries live fares, but everything around it (the landing pages, the multilingual content, the routing) is static and cached close to the user.

Features

• Multi-Source Flight Search: Aggregates fares from hundreds of airlines and travel agencies, surfacing the cheapest first
• Flexible Trip Planning: One-way, round-trip, and multi-city searches with adults, children, and infants across cabin classes
• Full Travel Stack: Flights plus hotels, eSIM data plans, and airport transfers
• Global By Default: 11-locale routing (including RTL Arabic) with hreflang, per-locale sitemaps, and currency handling
• Edge Localization: Geo-aware locale detection and apex-to-www redirects handled at the CDN edge

The search covers the shapes people actually book: a quick one-way, a round-trip, or a stitched multi-city itinerary, each with passenger mixes of adults, children, and infants and a choice of cabin class. Because Paglipat is a full travel stack rather than flights alone, the same trip can carry over into hotels, an eSIM data plan for the destination, and an airport transfer, so the booking flow does not stop at the boarding pass.

Being global is the default rather than an add-on. Eleven locales are wired through the routing layer, including right-to-left Arabic, and each one ships proper hreflang annotations, its own sitemap, and currency handling so search engines and travelers both land on the correct localized page. Locale detection and the apex-to-www redirect run at the CDN edge, which keeps that logic off the origin and out of the critical path.

AI relocation concierge

The site runs a live assistant that answers visa, accommodation, and flight questions. It is a tool-calling agent rather than a chat window bolted onto a landing page: the model is not trusted to remember a visa rule, only to decide which tool can look it up.

• Five tools, not a chatbot: check_visa, get_checklist, read_guide, search_hotels, and flight_prices. Each tool description states when to call it, not only what it does, because recent models reach for tools conservatively by default
• Two models, routed: a fast model classifies the turn and a stronger one answers only when the turn earns it, so simple questions do not pay for expensive reasoning
• Grounding over recall: no day count, fee, or eligibility rule may come from model memory. Every rule is returned with the date it was verified, and the model may only offer articles that exist in the catalog, so a retired post never turns into a dead link inside an answer
• Prompt caching as an invariant: the cached system prefix takes no clock, locale, or session id. A volatile byte there does not raise an error, it silently drops cache reads to zero and pays full input price on every turn, so a test asserts the invariant and a future edit fails CI instead of quietly costing ten times more
• Guardrails ordered by cost: parse, then daily budget, then IP rate, and only then the bot-defence round trip, so an abuser is rejected before spending a network subrequest. Caps run at five dollars a day, twenty messages per IP per hour, and thirty turns or sixty thousand output tokens per session
• Retention with code behind it: the privacy page promises visitors in every locale that transcripts are deleted after ninety days, so a purge job enforces it rather than a runbook step somebody remembers to run

The cost ledger is deliberately exempt from that purge. It stores token counts and prices, no question text and no IP hash, which is what makes long-run spend reconcilable without holding anything personal. The whole chat layer is covered by tests over the prompt assembly, the tool schemas, the guardrails, the routing decision, and the tool handlers.

Tech Stack

• Astro 7 with TypeScript (strict), output as a fully static site (~1,500 pages)
• Tailwind CSS v4 for styling
• MDX for the multilingual blog and legal/help content
• Cloudflare Worker for edge redirects, geo locale detection, and path-aware caching
• Anthropic SDK running on the Worker, streaming responses to the browser over SSE
• Cloudflare D1 for chat sessions, turns, and a per-token cost ledger
• Turnstile for bot defence on the chat endpoint
• astro-seo and sitemap-index for hreflang, canonicals, and structured data
• Deployed on DigitalOcean App Platform (static), fronted by Cloudflare

Astro 7 does the heavy lifting here. With TypeScript in strict mode and a fully static output, the build emits roughly 1,500 pages, which is what makes 11 languages of content feasible without a server rendering each request. Tailwind CSS v4 keeps the styling consistent across all of those pages, and MDX backs the multilingual blog plus the legal and help content so writing stays close to markdown while still allowing components where a page needs them.

The Cloudflare Worker carries the live logic in the stack. It handles edge redirects, geo-based locale detection, and path-aware caching, deciding what gets served from cache and what locale a visitor should see before the request ever reaches the origin, and it also hosts the concierge endpoint with its D1-backed sessions and cost ledger. On the SEO side, astro-seo and sitemap-index generate the hreflang tags, canonicals, and structured data that a multilingual site needs to avoid duplicate-content problems. The static build is deployed on DigitalOcean App Platform and fronted by Cloudflare, which is what keeps it cheap to run and quick to serve.

Design Philosophy

Static-first for speed and resilience, with an editorial hero and an emphasis on transparency, accessibility, and a fast path from search to booking on every device. Static-first also means fewer moving parts to break: with the pages precomputed and cached, a spike in traffic hits the CDN rather than an origin server. The editorial hero sets the tone, but the real goal is getting someone from a search box to a booking with as little friction as possible, on a phone as readily as a desktop.

Frequently Asked Questions

What is Paglipat?

Paglipat is a multi-airline flight metasearch and travel booking platform. It lets travelers compare and book flights across hundreds of airlines and travel agencies in a single search, and it also covers hotels, eSIM data plans, and airport transfers. The name comes from Tagalog and means “to transfer” or “to move.”

What is Paglipat built with?

It runs on Astro 7 with TypeScript in strict mode, output as a fully static site of around 1,500 pages. Styling is Tailwind CSS v4, the multilingual blog and legal/help content use MDX, and a Cloudflare Worker handles edge redirects, geo locale detection, and path-aware caching, and also runs the AI concierge, backed by D1 for sessions and cost. astro-seo and sitemap-index generate hreflang, canonicals, and structured data.

Where is Paglipat deployed?

The static build is deployed on DigitalOcean App Platform and fronted by Cloudflare, with a Cloudflare Worker running the edge logic. It was originally built on Next.js and rebuilt as a static-first, edge-optimized site.

How many languages does Paglipat support?

Eleven locales, including right-to-left Arabic. Each locale has hreflang annotations, per-locale sitemaps, and currency handling, and locale detection is geo-aware and handled at the CDN edge.