UniqTrip travel marketplace

Overview

UniqTrip was a travel application that helped users plan a trip from one product. Users could search for accommodation, discover activities available at their destination, inspect places on a map, and continue towards booking.

I worked on the existing product as a frontend developer. My contribution focused on the discovery experience: lists of available hotels and activities, API-driven result rendering, and Google Maps integration.

This was a team product. I contributed frontend functionality rather than owning the complete platform or booking system.

Product context

Planning a trip often requires several separate services: one for accommodation, another for activities, and a map for understanding where each option is located.

UniqTrip brought this information into a connected flow where users could:

• search for hotels at their destination;
• browse current activities and other things to do;
• understand where results were located;
• move from discovery towards booking.

My contribution

My work included:

• implementing hotel result lists;
• implementing lists of activities available at the selected destination;
• connecting frontend views to backend APIs;
• displaying places and results through Google Maps;
• supporting interactions between result cards and map locations;
• maintaining responsive behaviour across the user-facing interface.

The main goal was to help users answer three practical questions:

1. Where can I stay?
2. What can I do at the destination?
3. Where are these places located?

Hotel and activity discovery

I worked on interfaces that presented available accommodation and activities for the selected destination.

The frontend transformed API responses into browsable result cards containing the information available for each item, such as:

• name;
• location;
• images;
• descriptive information;
• availability-related data;
• actions that continued the product flow.

Travel data can be incomplete, so the components also needed to remain usable when optional images, descriptions, coordinates, or other fields were unavailable.

Google Maps integration

I used the Google Maps API to help users understand where hotels, activities, and other relevant places were located.

The map was part of the discovery workflow rather than a decorative element. The implementation required coordinating:

• coordinates received from APIs;
• map markers;
• selected results;
• map positioning and zoom;
• interactions between the list and map;
• loading and incomplete-coordinate states.

The list and map represented the same data in two different forms:

Hotel or activity list
        ↕
Selected result
        ↕
Marker on the map

Selecting an item needed to identify the corresponding location without making the user lose their place in the results.

Frontend integration

The application consumed backend data through REST APIs. On the frontend, I worked with:

• asynchronous data loading;
• API response transformation;
• reusable result components;
• empty and unavailable-result states;
• responsive layouts;
• external Google Maps APIs;
• list, card, and marker interactions.

Technical challenges

Keeping list and map state synchronised

The catalogue and map needed a consistent selected state. Selecting a hotel or activity had to focus the relevant map marker while keeping the corresponding result identifiable in the list.

Working with a third-party map API

Map initialisation and updates depended on script availability, valid coordinates, and component lifecycle. Results could change without creating unnecessary map instances or leaving stale markers behind.

Presenting variable travel data

Hotels and activities did not always provide the same set of fields. The UI needed to handle optional information while retaining a consistent structure and clear user actions.

What this work demonstrates

This project represents early commercial frontend experience involving:

• work within an existing product and team;
• API-driven catalogue interfaces;
• third-party Google Maps integration;
• synchronisation between list and geographic views;
• responsive product UI;
• travel-discovery user flows.

Key takeaway

Location is part of the decision-making interface in a travel product.

A list explains what accommodation or activity is available, while a map helps users understand how each option relates to the destination and other places. Combining both views created a more useful discovery experience than treating search results and geography as separate features.