SproutRoute — family trip planner
SproutRoute is a family trip planner that brings day-by-day itineraries, route maps, packing, and safety guidance into one plan.
1
Proof
12.2 s
First city ready
One production run: Tokyo → Kyoto → Hakone, 8 days, Sep 9, 2026
25.0 s
Full three-city route ready
Same run; timing starts after route confirmation
2
The work
6 chapters
2.1
The problem
A list of attractions isn't a trip plan. Families also have to decide which cities to visit, how to move between each day's stops, what to pack, and what to check before leaving.
2.2
Why it mattered
A plan families can rely on needs clear loading states, recoverable failures, and an honest line between AI suggestions and sourced information.
2.3
What I did
AI for suggestions, rules and APIs for facts. AI proposes the itinerary; rules produce packing lists; dedicated services supply weather, place details, and map directions.
Moved packing from AI to rules after the AI output proved inconsistent.
Put safety highlights on the main plan instead of a separate tab. The full guidance stays one click away.
Plan cities in parallel. Two city plans run at once, and packing and safety start without waiting for the itinerary.
I took SproutRoute from the first idea through design, implementation, and launch, and I operate it.
2.4
What went wrong
A Japan demo exposed missing attractions, slow generation, and maps that showed a city instead of the day's route. I traced the browser requests and production timings, repaired the failure paths, and rechecked the full trip on desktop and a narrow screen.
AI still proposes venues and safety tips. A map route doesn't prove every suggestion is open, suitable, or safe; broader venue and safety evaluation is the next piece of work.
2.5
Stack
React and Express on Railway, Google Maps, weather and place-detail APIs, and a model chosen per task (Gemini Flash for itineraries).
2.6
A route for each day
Named attractions stay on the map even when coordinates are missing, and Google Maps connects the day's stops in itinerary order. The map answers "how do we get between these?" instead of showing a city pin.
Build notes: model choice, reliability, architecture
Model choice against the real workload
I compared three models on the production prompt: Tokyo trips of three and six days for adults, and a three-day Kyoto trip with children. Two passes gave six samples per model. GPT-5.4 nano averaged 28.1 s and produced an invalid activity reference and a repeated activity. Gemini 3.8 Flash averaged 13.8 s and met the requested activity coverage and reference checks, so it runs itineraries. Gemini 3.5 Flash Lite averaged 10.7 s but returned fewer than four activities on some days.
The benchmark checks output structure and coverage. It doesn't establish venue accuracy, opening hours, or safety quality.
Reliability fixes after the Japan demo
API-origin fixes and explicit retry and edit actions replaced blocked requests and silent regeneration after a stream error.
Named attractions stay on the map without coordinates; the route follows itinerary order.
I restored the protected metrics dashboard's sign-in and metric mappings, then used stage and model timings to find the slow calls.
Architecture
Parse and review: the parser extracts travel constraints, and travelers confirm or reorder a multi-city route.
Plan and stream: the backend resolves destinations, retrieves weather and cached attraction candidates, and streams itinerary results.
Prepare: rules produce packing items; separate requests supply safety guidance and place details.
Measure and recover: protected metrics record model latency, trip stages, and errors. Partial results stay visible when a later stage fails.
Checks
533 unit and integration tests and 73 browser tests passed for the September 9 release. The 25.0 s figure is one observed run, not a response-time guarantee.
3
Contact
Hiring for a product area?
I am looking for Principal / Staff IC ownership of a product area.