The problem
I started Trekka after travelling frequently from Singapore. Planning a visit to a country I knew little about meant opening dozens of tabs and piecing together advice from blogs, maps, forums, booking sites, and videos. The research took a long time, and most tools stopped being useful as soon as the itinerary was written.
Travelling with friends added another layer. Decisions happened in a group chat, expenses lived somewhere else, and booking details were spread across inboxes and screenshots. I wanted the research, the plan, and the practical parts of the trip to stay together in one app that remained easy to use while everyone was on the move.
What I built
Trekka starts with a travel profile. It learns a person's preferred pace, budget, interests, and travel style before suggesting destinations or attractions. Web research provides current information, while feedback from completed trips can improve the profile over time. The aim is to recommend places that fit the traveller, not return the same famous tourist list that a generic chatbot gives everyone.
The itinerary builder moves through nine stages, from an initial Vibe Check and route ideas to transport, daily plans, accommodation, and a final review. AI is used for the creative parts, such as proposing routes and drafting a day plan. Pacing, budget calculations, route changes, and undo behavior are handled with normal application logic so they remain fast and predictable.
The web app handles deeper planning on a larger screen. The mobile app changes focus once the trip begins, surfacing the next activity, directions, bookings, shared expenses, group votes, and check-ins. Those features are tied to the same itinerary rather than behaving like a collection of unrelated travel utilities.
Decisions and tradeoffs
A model only where creativity earns its cost
Vibe scoring, pacing, budget estimates, and transit options use ordinary application logic. They are fast to recalculate and do not need generated text. AI is reserved for proposing routes, drafting day plans, and preparing the final itinerary.
Stateful bookings kept out of the stateless integrations layer
Booking platforms need a stateful connection, while weather, maps, and currency services usually need a single request. Keeping those integrations separate means the AI layer never handles a booking connection directly, and the authentication details stay in one place.
A profile before a prompt
Recommendations begin with stored preferences and past travel feedback, not an empty chat box. This gives the system something specific to optimise for and makes it possible for suggestions to improve over several trips.
Different interfaces before and during a trip
Planning benefits from a detailed web interface, but that same density is inconvenient while travelling. Mobile reduces the itinerary to the next useful action and keeps group decisions, expenses, and bookings close at hand.
What I learned
Personalisation needs more structure than a prompt. A reusable travel profile, explicit preferences, and feedback from previous trips give the system a clearer basis for recommendations than a blank chat box.
I also learned that planning and travelling are different interface problems. A detailed web workspace is useful when comparing routes and budgets, while the mobile app should hide that complexity and show the next thing the traveller needs.
Result
Trekka is still pre-launch. The FastAPI backend, planning pipeline, React web app, and Expo mobile app are functionally built, with tests covering accounts, trips, budgets, groups, bookings, and export. The next meaningful test is not another feature. It is using Trekka for real trips with a group and seeing whether the recommendations feel personal, the plan survives changes, and the mobile experience removes more friction than it creates.
