Loading...
All Projects
AI & DataLIVE
TRAVLIST
AI travel planning, ETL-first: the dataset is computed before the question is asked.
I built this AI travel-planning platform ETL-first: a Python pipeline pre-computes the travel dataset into Postgres, then fans out to Elasticsearch, Neo4j, and Qdrant. Answers return sub-second and AI costs stay predictable, instead of a 6-to-60-second LLM call per query. In production on Railway and Vercel.
- Client
- Travlist
- Role
- Architect & Data Engineer
- Timeline
- 2025 — Present
ETL-FIRST AI
- Backend tests
- 4,862
- Travel entities
- 400k+
- Prompt-eval pass rate
- 97.8%
- Tables, RLS default-deny
- 117
The Challenge
The naive way to build AI travel planning is to call an LLM for every question. That means 6 to 60 seconds per answer, costs that scale with curiosity, and a product that gets worse exactly when it gets popular. I wanted sub-second answers, predictable spend, and data I could actually test, which meant treating AI as a layer over a computed dataset rather than a substitute for one.
The Solution
I built the platform ETL-first inside a pnpm monorepo. A Python scraper with a hard $50 budget cap collects and normalizes the raw travel data into Postgres: 84 entities, over 400k rows of travel content, managed through 159 additive-only migrations that a lint hook enforces, so nothing gets deleted, ever. From Postgres the dataset fans out to three query stores: Elasticsearch for search, Neo4j for relationships, Qdrant for semantic similarity. The NestJS 11 + MikroORM backend serves it through 4,862 tests, the Next.js 15 front end through 72 Playwright specs, and the AI layer passes a promptfoo eval suite at 97.8%. Every one of the 117 tables is RLS default-deny.
The Outcome
Travlist is in production on Railway and Vercel. Answers that would have taken an LLM call per query return in sub-second time from the stores, and the AI budget is a known monthly number instead of a surprise. The eval suite catches prompt regressions before deploys, and the no-deletes migration rule means the 400k-entity dataset only ever grows.
Highlights
- ETL-first architecture: answers come from pre-computed stores, not 6-to-60-second LLM calls per query
- One Python pipeline feeds Postgres, then fans out to Elasticsearch, Neo4j, and Qdrant
- pnpm monorepo: NestJS 11 + MikroORM backend, Next.js 15 front end, budget-capped Python scraper
- 84 entities and 159 additive-only migrations, with a lint hook that rejects destructive changes
- 4,862 backend tests, 72 Playwright specs, and a promptfoo eval suite passing at 97.8%
- Row-level security default-deny on all 117 tables
Technology
NestJSNext.jsPythonElasticsearchNeo4jQdrant
Have a project like this in mind?
START YOUR PROJECT