Lumoria
CONTEXTUAL TRAVEL PLANNING SYSTEM
A travel product that starts from where the user actually stays and combines interests, time, mobility and weather context.
Before the technical detail, read the problem, decision and evidence as one narrative chain.
- STATUS
- Live
- TYPE
- Product · Travel planning
- ROLE
- Co-product development · Systems and technical architecture
- PLATFORMS
- Web
What was the problem, what changed, what is different now?
Before the technology details, this shows the transformation: the original bottleneck, the intervention, and the outcome that can be verified today.
PROBLEM
Several variables had to become one route decision without exposing a complex planning dashboard to the user.
INTERVENTION
We treat hotel/location origin as fixed context and combine interests, duration, mobility preference and weather into one route context.
OUTCOME / CURRENT STATE
Lumoria is live with contextual routes, discovery memory and weather awareness combined into one travel flow.
- EVD-02 / Transformation
- Generic city list → route starting from the real origin
- EVD-03 / Decision context
- Interests · duration · mobility · weather
- EVD-04 / Product outcome
- One route-decision flow
ROI, revenue lift or percentages are shown only when a verifiable source exists. Otherwise the proof is the working product, distribution, system outcome and sourceable scope — never invented metrics.
Context → itinerary completion rate
Share of planning flows with valid origin, interest, duration, mobility and weather context that produce a completed itinerary for the user.
Route Context valid → itinerary generation started → completed itinerary displayed.
Route Context and itinerary lifecycle events; the vendor source must be verified before publishing a baseline.
No verified baseline is published for this case yet; no value is invented and no numerical claim is made before the source is verified.
Context
Generic city lists give everyone the same overview. In real trips, origin, duration, walking preference and weather directly change route quality.
Problem
Several variables had to become one route decision without exposing a complex planning dashboard to the user.
My role
- Co-product development
- Systems and technical architecture
Solution
We treat hotel/location origin as fixed context and combine interests, duration, mobility preference and weather into one route context.
What was built
- Location / hotel-based route origin
- Interest and duration context
- Walking preference and weather awareness
- Discovery memory
- Form validation and responsive planning flow
System architecture
Technical stack
FRONTEND
React 19 · TypeScript · TanStack Start · TanStack Router · TanStack Query · Tailwind CSS 4 · Radix UI · React Hook Form
BACKEND / DATA
Supabase
VALIDATION
Zod
RUNTIME
Vite · Nitro
Important engineering decisions
- Build route context from the real origin rather than the city center
- Expose the multivariable system as one decision flow
Code / architecture excerpts
01const routeContext = {02 origin: hotel.location,03 interests: user.interests,04 duration: trip.duration,05 mobility: user.walkingPreference,06 weather: forecast,07};08
09const itinerary = buildRoute(routeContext);Result / current state
Lumoria is live with contextual routes, discovery memory and weather awareness combined into one travel flow.
Engineering takeaways
- In planning products, good defaults are more valuable than more options.
- Location context should be the first input to recommendation, not a final filter.
OUT-LIVE / VISIT PRODUCT
Lumoria
EVIDENCE / AUTHORITY
What does this case prove?
The roles and decisions documented here are not portfolio decoration; they are concrete evidence for the work described on the services and capabilities pages.
NEXT PROJECT
PRJ-06Good Move