My responsibilities
I developed Travel Junior as a personal product. The approved record attributes the application to me and documents its stack and capabilities; it does not establish a separate team or client engagement.
Problem
Travel Junior turns a trip-planning request into an itinerary that a visitor can use and export. The engineering challenge is connecting model output to a complete application rather than stopping at a generated answer.
Context and constraints
The approved record identifies Travel Junior as a live personal product with a private repository. Repository documentation establishes capabilities, not independently measured adoption, uptime or performance. No user counts or business outcomes are claimed.
Existing architecture
The documented stack uses Svelte and TypeScript for the interface, Fastify for the backend, Gemini for AI generation, Google Places for places data and PostgreSQL for storage.
Investigation and approach
The documented product brings together model integration, external places data, caching, validation, fallbacks, metrics and PDF export. The master record does not retain a detailed investigation log, so this account does not invent a sequence of design experiments.
Core engineering decision
The product includes backend responsibilities around the model: data flows, external integration and handling the generated result. The specific validation rules, cache policy and fallback triggers are not established in the approved record.
Solution
A live itinerary-planning application with AI generation, places integration and PDF export. Caching, validation, fallback behavior and metrics are documented parts of the project.
Architecture and implementation
The diagram shows the main documented components. It is a conceptual view, not a reconstruction of every request or deployment boundary.
Application components
- Svelte / TypeScript interface
- Fastify backend
- Gemini + Google Places
- PostgreSQL
Supporting capabilities
- Validation and fallbacks
- Caching and metrics
- Itinerary and PDF export
Result
A live public personal product at tripplanner.alisquare.com, confirmed in the approved October 2026 record. The code remains private. No adoption, conversion, revenue or latency result is established.
Lessons and tradeoffs
This project illustrates the work around a model integration: input/output handling, third-party data, fallbacks and a useful export. Caching and validation policies need to match a product’s freshness and correctness requirements; no particular measured tradeoff is claimed here.
What I would carry forward
For further development, retain representative planning inputs and failure cases, evaluate generated itineraries and measure actual product use before claiming quality or business improvements. These are next-step recommendations, not completed measurements.