The whole trip. In one place.
What did this project ship?
Public trips still being planned, and private trips for the people invited. The assistant can read this group and the weather. It cannot read a trip the caller is not on, and it cannot keep calling tools after the budget.
- Public trips
- Join request
- Day plan
- Group chat
- Expenses
- Trip AI
- Industry
- Travel
- Country
- India
- Team
- 2 people
- Scope
- Community + AI
Find a trip. Join it. Ask for the day.
01
One row, two audiences, one model
Members, the day, the photos, and the money sit on one trip. A stranger has to be able to open a public trip that is still in planning. The same row, if the policy is wrong, is the private chat and the expenses. The assistant runs in an edge function. The OpenAI key never ships on the phone.
02
Engineering challenges
A public trip and a private trip are the same table. The assistant will follow a trip id in the message, invent a price, and keep calling tools. A video is one body. A pending expense is not the group's spend.
- 01Discover is a select on the same table
Someone who has not joined has to read a public trip that is still in planning. That select, pointed at a trip that is not public, returns the members, the messages, and the expenses.
- 02The message can name another trip
Chat is free text. get_trip_data takes an id. If that id comes from the message instead of the trip this request was opened on, a member of one group reads another group's snapshot, including expenses.
- 03The day is a price list the model will fill
The daily plan asks for activities with a time, a duration, a category, and a cost, plus weather advice. With no tool result, the model writes a forecast, a ticket price, and opening hours. The group can save that day onto the trip.
- 04Each turn is another billed call
Chat, recommendations, and the daily plan can each call get_trip_data and get_weather again. The history grows by the tool results. Members, expenses, messages, and the itinerary get loaded on every turn. The model does not stop. The function has to.
- 05A video is one request body
A photo or a video goes up as a single body. A large file dies mid-request and starts over, and the trip's media fills with partial objects if the phone does not refuse a file past the cap first.
- 06Pending is not the group's spend
Any member can insert an expense they paid. Until an owner or an admin approves it, that line is not what settlement should add up. Left visible to the whole trip, it moves the shared total before anyone responsible has seen it.
03
How we solved them
The policy decides who can read the row. The function pins the trip id and drops the tools when the turns run out. Weather comes from Open-Meteo. A file past the cap never starts. An expense stays pending until an owner accepts it.
- The policy decides who reads it
A trip is visible to its creator, to a member, or to anyone when it is marked public. Discover queries the public rows that are still in planning. Join is request_trip_join, then a push to the owner and the admins.
- The trip id is pinned
The function rejects an id that is not a UUID and binds the valid one for the request. get_trip_data cannot supply a different id. The read uses the caller's token. Email and contact are dropped unless the role is owner or admin.
- Weather comes from Open-Meteo
get_weather asks Open-Meteo for that place and date, and returns activity hints from the forecast. The chat instruction requires bookings, prices, and hours to come from a tool.
- The loop has a last turn
After the tool turns, the function calls the model once more with the tools removed. A snapshot read is capped per field. A generated day sends a slice of the saved itinerary and a slice of the forecast.
- Chunks, and a hard size
A member inserts a photo on the trip. A file past the cap is refused. A large file, or any video, goes up in chunks, a few at a time.
- Pending until an owner accepts
A member inserts an expense they paid. Pending stays visible to that payer and to an owner or admin. The rest of the trip sees the line once it is approved. The phone keeps a cap on new expenses and a cap on edits.
04
One assistant. Two tools.
Ask about this trip. The edge function calls OpenAI with the signed-in user's token. The trip id is fixed for that request. The model can load the saved record, or the weather for a place and a date. When the tool turns run out, the tools are switched off and the answer has to finish.
- 01Group
- 02Places
- 03Record
- 04Weather
- 05The day
- 01Who is on this trip
Members the caller is allowed to see, with the preferences stored on them: food, interests, budget, and how they travel.
- 02What the trip already saved
Place suggestions and the itinerary on this trip. The tool reads those rows.
- 03An allow-list, as the user
The fields are trip, members, expenses, messages, itinerary, stays, daily plans, place suggestions, and funds. The query uses the caller's token.
- 04The sky for that date
Open-Meteo for the place and the date. Rain above 50% points indoors. A sunny day under 30% points outside.
- 05One JSON plan
A separate call returns the day: activities with a time, a duration, a category, and a cost, plus weather advice and packing tips. The group can keep it or change a stop.
05
System design
Everything hangs off one trip id, with row-level security on each child table. Chat, recommendations, and the daily plan are three actions on one function, and each action has its own token cap.
- 01Everything hangs off the trip
Members, messages, expenses, splits, checklist items, itinerary activities, stays, and photos use the trip id. Row-level security is on each of those tables.
- 02Three actions, one key
Chat, recommendations, and the daily plan are three actions on the travel-ai function. Chat history travels with the request. The OpenAI key and the model name stay in the function. The default model is gpt-4o-mini.
- 03The day is JSON
The daily-plan action asks for one object: date, location, activities with time, duration, category, and cost, then weather advice and packing tips. Recommendations are a separate list. Neither call books anything.
- 04The thread has its own tables
Messages, read receipts, delivery receipts, reactions, and typing each have a table. The phone subscribes to insert, update, and delete on messages. A message from someone else calls mark_messages_as_read. A timer refreshes status beside that subscription.
- 05Money, then Stripe
Splits hang off the expense. A stay can point at an expense. Settlement is a screen on the trip. Payment intents and subscriptions are their own edge functions, with their own caps on the phone.
06
What a trip includes
The trip as the group uses it: who can see it, who can join, the day, the assistant, the list, the photos, the chat, and the money.
- 01Private, or public
A closed trip for the people you invited. A public trip anyone can open while it is still being planned.
- 02Find one and ask to join
Discover lists those public trips, newest first. Search filters the list by name, destination, and description. The host and the admins get a push. They decide who walks in.
- 03The day, written once
Activities with a time, a place, and a cost. Stays with a check-in, a check-out, and a type: hotel, hostel, Airbnb, resort, or other.
- 04Ask for the day
The assistant reads this trip and the weather, then returns a plan. The group can keep it or change a stop.
- 05Packed for this place
Checklist items live on the trip, next to the day they belong to.
- 06The roll for this trip
A photo keeps a caption, a place, and when it was taken. Members upload. Members can see them.
- 07Talk where the plan is
Messages, reactions, and read state on the same trip as the day.
- 08The shared cost
Add an expense, split it, and open settlement. An owner or an admin approves a pending line.
07
What we built
AonHive designed and built TripGlide for iOS and Android: public and private trips, join requests, the day, the checklist, stays, chat, photos, and expenses. The assistant is the travel-ai function, with the trip id pinned, two tools, a hard stop on turns, and the OpenAI key off the phone.
08
App performance & engineering
A 1-second app load and responsive everyday use, backed by the technical foundations behind TripGlide.
From launch to planning
Shown on send, synced live
Memory and disk, reused everywhere
Parallel, with progress per photo
One app for iOS and Android
Queued on device, retried with backoff
Chat, picks, and day plans
09
What we delivered
- TripGlide for iOS and Android
- Public and private trips
- Discover for public trips still in planning, with search
- Join requests, with a push to the host and admins
- Itinerary activities
- A generated day the group can edit
- Recommendations from the same assistant
- Checklist items on the trip
- Stays with dates, cost, and a link to an expense
- Group chat: messages, read receipts, delivery receipts, reactions, and typing
- Trip photos with a caption, a place, and a time
- Expenses, splits, and approval by an owner or admin
- Settlement
- Stripe payment intents and subscriptions
- The travel-ai edge function, with the key off the phone
- Push notifications
10
Technology
- React Native
- Supabase
- OpenAI
- Expo
