A trip assistant that still answers with roaming switched off
A companion app for a tour operator's guided trips, whose assistant answers questions about a traveler's own itinerary on-device. The moment people land abroad they turn data roaming off, and most apps go dark exactly when they're needed.
The shape of the work
- Industry
- Tour Operators
- Duration
- 12 weeks
- Cooperation model
- Fixed price, phased
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
What we were brought in to do
Travelers had a perfectly good app that stopped working the moment they landed and switched roaming off. We rebuilt it so the questions people actually ask in-trip (when's my transfer, what's included, where do I meet the guide) are answered on the phone, from their own trip data, with no connection at all.
A tour operator whose app worked beautifully on hotel Wi-Fi and went dark the moment travelers landed and switched roaming off. The support cost was concentrated and visible in the call logs: guides and the office fielding the same handful of questions (transfer times, what's included, where to meet) clustered in exactly the hours travelers were offline.
Mobile Engineering & AI
Where the old way broke
Every question the app couldn't answer became a phone call to a guide or the office, and the calls clustered in exactly the hours when travelers were offline and anxious. The assistant only worked on hotel Wi-Fi, which is the one place travelers didn't need it.
The assistant required a connection for every answer, including questions that were entirely about data the traveler had already been sent. Asking what time is my transfer needed a round trip to a server to read a field from an itinerary that was fixed at booking. That specific absurdity is what made the offline rebuild worth twelve weeks.
We shipped one React Native codebase that downloads each traveler's itinerary the moment they book, then runs a small assistant on-device against it. Voice input handles the hands-free case (walking, luggage in both hands), and heavier open-ended questions route to the cloud only when there's a connection to use.
Itinerary on the device
The full itinerary downloaded at booking, before the trip and the roaming decision.
The itinerary downloads at booking, which is the last moment the traveler is reliably on their own Wi-Fi and before the roaming decision gets made. Flights, hotels, transfers and confirmations are stored in SQLite as structured records instead of a cached page, so the assistant can answer questions about them, not just re-display them. Changes sync when a connection appears.
- Downloaded at booking, before the roaming decision
- Stored as structured records, not a cached page
- Changes reconcile whenever a connection appears
The pre-trip download: itinerary, two city maps, documents and the assistant’s trip data pulled onto the phone over Wi-Fi at booking, six days before departure, with the itinerary kept as 46 structured records.
Answers with roaming off
Ask, with roaming off: two questions answered on the phone from the traveler’s own itinerary records, above the six they asked earlier today.
A small assistant running on-device against the traveler's own itinerary.
A small language model runs on the device against the traveler's own itinerary, so what time is my transfer and which terminal am I in answer with the phone in airplane mode. The model is scoped to itinerary reasoning, with no general knowledge to carry, which is what lets it be small enough to run locally and reliable enough to be worth asking.
- On-device model answers with the phone in airplane mode
- Scoped to itinerary reasoning, not general knowledge
- Open-ended questions routed to the cloud only when connected
Voice for hands-full moments
Speech input for the walking, luggage-in-both-hands case that dominates travel days.
Travel days are hands-full days. Speech recognition runs on-device so voice works without signal, and the assistant answers aloud as well as on screen for the walking-through-a-terminal case. It's push-to-talk, never always-listening, because a permanently open microphone isn't a trade a travel app has earned.
- On-device speech recognition: voice works without signal
- Spoken answers for walking, luggage-in-both-hands moments
- Push-to-talk, never always-listening
Push-to-talk voice input mid-sentence, recognized on the phone, with the six questions that answer on-device listed against the one that needs a connection.
What we built together
- 01
Pulled the full itinerary onto the device at booking, before the trip starts
Booking was chosen as the moment after testing the alternatives: a download prompted at check-in or on arrival is one most travellers never see.
- 02
Ran the itinerary assistant on-device so it answers with roaming off
It's stored as structured records instead of a cached page, so the assistant can reason about it, not only redisplay it.
- 03
Added voice input for the hands-full moments that dominate travel days
A small on-device model scoped to itinerary reasoning answers with the phone in airplane mode, and speech recognition runs locally so voice works too.
- 04
Reserved cloud calls for open-ended questions, only when signal allowed
Open-ended questions route to the cloud only when a connection exists. The cloud is the exception, never the default path with an offline fallback.
Operational results after launch
-38%
In-trip calls to guides
All of them
Itinerary answers available offline
4.7★
App store rating
In-trip calls compares the operator's own guide and office call logs for the season after launch with the season before, on comparable trip volumes. Offline itinerary answers is a capability claim: every question about itinerary data is answerable on-device. The rating is the rolling store average for the six months after launch.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Phase by phase
Phase 1: Pre-load
Before they land
Pulled the full itinerary onto the device at the moment of booking, well before the trip starts.
- Sync design
- Local schema
Phase 2: Answer offline
On-device, against their own trip
Ran the itinerary assistant on-device so it answers with data roaming switched off.
- On-device assistant
- Grounding logic
Phase 3: Add voice
Hands full, walking
Added voice input for the hands-free moments that make up most of a travel day.
- Speech input
- Voice UX
Phase 4: Reserve the cloud
Only when there is signal
Routed open-ended questions to the cloud only when a connection was actually available.
- Routing policy
- Graceful degradation
- Store release
The stored map of Marenca with the day’s walking route, six stops and the distance between them, loading nothing.
About our collaboration
A cross-functional team of 5 worked on a fixed price, phased basis over 12 weeks, covering React Native build, On-device assistant, Voice input. We ran a standing mid-week checkpoint and written decisions in place of status meetings. Nothing shipped that they had not seen working first.
Phased so the itinerary download and the offline data model landed before any assistant work, because the assistant is only as useful as what it can read without a connection. Field testing was done in airplane mode on real itineraries, not with a throttled connection, since the failure mode being fixed is no connection at all, not a slow one.
What we'd carry into the next one
Travelers switch roaming off the moment they land, so an online-only assistant goes dark exactly when it's needed.
Roaming off is the normal state of an international traveler, so an online-only assistant is unavailable during precisely the window it was built for.
Grounding the assistant in the traveler's own itinerary made a small on-device model sufficient.
A model that only has to reason over one itinerary can be small; the size problem is caused by general knowledge, which this use case never needed.
Voice wasn't a novelty here: both hands are genuinely occupied for most of a travel day.
Push-to-talk voice earned its place because both hands are occupied for most of a travel day. It's an accessibility answer to a physical constraint, not a novelty.
Day four, roaming off
Ask about the trip, and the phone already knows.
Pick a kind of question a traveler asks mid-trip. Each one shows the records the on-device assistant reads from the itinerary downloaded at booking, the answer it builds, and what it honestly can’t know without a connection. Switch the Wi-Fi on to see which questions move to the cloud, and which never do. Use the arrow keys once a tab is focused.
- Transfer 3.pickupFri 9 Oct, 08:30
- Meeting point 7.placeHotel Almirante, front entrance
- Transfer 3.duration2 h 10 min
One traveler’s invented trip. The step-by-step reveal is illustrative playback, not a measured response time.
From a confirmed booking to an answer with roaming off
The assistant is only as useful as what it can read without a connection, so the data model landed before any assistant work, and the cloud is a path the app takes when it can, never one it depends on.
- 01 · TriggerBooking confirmedThe itinerary downloads at booking: the last moment the traveler is reliably on their own Wi-Fi, before the roaming decision.
- 02 · StoreSQLite on the phoneFlights, hotels, transfers and confirmations land as structured records, not a cached page, so they can be reasoned about.
- 03 · EngineOn-device assistant + speechA small model scoped to itinerary reasoning answers in airplane mode; speech recognition runs locally, push-to-talk only.
- 04 · StateReconcile on connectionChanges from the operator sync whenever a connection appears. Nothing in-trip waits on one.
- 05 · DeliverScreen, voice, or cloudAnswers show on screen and aloud. Open-ended questions go to the cloud only when there's signal, and never by default.
Scoped answers, push-to-talk & airplane-mode testing
Answers come from their own trip
The on-device model is scoped to itinerary reasoning over the traveler's own records, with no general knowledge in the way. Anything outside the trip goes to the cloud, and only when a connection exists.
The microphone opens only while held
Voice is push-to-talk, never always-listening, and speech recognition runs on the phone, so voice works without signal. A permanently open microphone isn't a trade a travel app has earned.
No connection is the tested case
Field testing ran in airplane mode on real itineraries, never on a throttled connection. Changes from the operator reconcile whenever a connection appears.
Does your app need to keep answering after your customers switch roaming off? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsDynamic pricing that reads demand in real time
A revenue-management engine that turns booking pace, seasonality, and local events into nightly rate recommendations across a multi-property portfolio.
Hotels & Accommodation · 12 weeks
Web PlatformsThe invoice and the trip it pays for were separate records, so nobody could say which trips were unpaid
A booking and invoicing system for a travel agency where every invoice line points at the trip component it bills, and every payment points at the bank account it landed in. "Which trips are unpaid" becomes a query instead of an afternoon.
Travel & Tourism · 10 weeks
Web PlatformsA booking platform tuned from search to checkout
A reservation platform where the search-to-checkout path is designed around real traveler behavior, then engineered to load fast and hold up under seasonal spikes.
Travel & Tourism · 16 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
