The problem
A trip needs local advice, a map, somewhere to stay, somewhere to eat, a way to get around, and sometimes a translator, usually spread across five different apps instead of one.
What I built
I built Tourist Guide end to end, with separate user and admin roles. Travellers can browse tourism advice and posts with image viewers, confirm addresses on a map, request taxi assistance, and reach a translator or browse a translator directory when a language barrier comes up. Admins manage hotel, restaurant, and special-service listings that travellers browse inside the app. The app surfaces this information rather than booking it: it doesn’t connect to any real hotel, taxi, or reservation backend.
Tech stack
The Android client is written in Java, backed by Firebase and Google Maps / Location for address confirmation and mapping.
What I learned
A broad travel app needs a clear service taxonomy, or more features make navigation worse.
Splitting advice, maps, hotels, restaurants, and translation into distinct sections, rather than one flat menu, was the difference between a genuinely useful trip companion and a pile of unrelated screens.