Inspiration
I built Trailsmate because planning an outdoor weekend should feel exciting, not fragmented.
For adventure travel in Maharashtra, the discovery process is still scattered across WhatsApp groups, Instagram pages, operator posts, and personal recommendations. A traveler may know they want to do something this weekend, but comparing trekking, rafting, camping, kayaking, or paragliding options takes too much effort. Prices are often unclear. Operator credibility is hard to judge. Details like itinerary, inclusions, group size, difficulty, and safety standards are spread across different places.
Trailsmate was inspired by a simple product question: what if booking a Sahyadri adventure felt as smooth as booking a hotel or a flight?
The goal was to create one trusted marketplace where travelers can discover outdoor experiences, compare real details, and complete a booking flow in minutes.
What Trailsmate does
Trailsmate is a booking marketplace for Maharashtra's outdoor adventures.
Users can browse curated experiences across destinations such as Kalsubai, Kolad, Bhandardara, Devkund, Rajmachi, Harishchandragad, Kamshet, and Andharban. They can filter by activity category, destination, search text, popularity, rating, or price. Each listing includes the information a traveler needs before committing: itinerary, difficulty, duration, group size, operator profile, rating, reviews, highlights, inclusions, exclusions, gallery, and transparent pricing.
Once the user chooses an experience, Trailsmate guides them through a complete reservation flow. The user selects a date, chooses the group size, reviews the price breakdown, completes a demo sandbox payment, receives a booking reference, and can view the confirmed trip inside My Trips.
For operators, the product concept is equally clear. Trailsmate gives local adventure providers a clean marketplace layer for discovery, trust, and conversion while they continue to handle the actual on ground experience.
How it works
Trailsmate is built around a shared adventure data model.
The core entities are activities, destinations, operators, listings, reviews, and bookings. The browsing system uses that data model to power category filters, destination filters, search, sorting, listing cards, and detail pages.
The catalog logic can be summarized as:
[ results = filter(listings, category, destination, query) ]
Then the selected sorting strategy is applied:
[ rankedResults = \begin{cases} sortByRating(results) & \text{if user selects top rated} \ sortByPrice(results) & \text{if user selects lowest price} \ results & \text{if user selects popular} \end{cases} ]
The booking engine calculates price from the selected listing and guest count:
[ subtotal = pricePerPerson \times guests ]
[ serviceFee = round(subtotal \times 0.05) ]
[ total = subtotal + serviceFee ]
When the demo payment is completed, Trailsmate generates a booking reference, creates a booking object, saves it locally, and shows the confirmed trip in My Trips. This gives the demo a complete marketplace loop from discovery to confirmation.
The product flow is:
Browse experiences. Filter by destination or activity. Open a detailed listing. Choose date and guests. Review transparent pricing. Complete sandbox payment. Receive confirmation. Save trip locally.
How I built it
Trailsmate was built as a static React web application.
I used React 19 for the interface, Vite 8 for fast development and production builds, and Tailwind CSS 3 for a responsive design system. The app is deployed on GitHub Pages and runs fully in the browser.
The application is structured as a small marketplace system. The shared domain data lives in a central data file. The browse page acts as the catalog engine. The detail page turns a listing into a rich travel product page. The booking page handles date selection, guest count, price calculation, sandbox payment, confirmation, and My Trips persistence.
For persistence, I used browser localStorage to store confirmed bookings. This keeps the demo lightweight and gives users a real sense of continuity without needing a backend. I also added a generated booking reference so each confirmed trip feels concrete instead of temporary.
The interface was built with a mobile first approach. Adventure travelers often plan from their phone, so the browsing cards, destination sections, sticky booking panel, and confirmation flow are designed to feel fast and readable on smaller screens.
Challenges
The biggest challenge was making a static demo feel like a real marketplace.
A travel marketplace has many moving parts: destinations, operators, categories, listings, reviews, itinerary details, booking state, price calculation, payment state, and confirmed trips. The app needed to make all of these pieces feel connected without relying on a backend.
Another challenge was designing the catalog experience. Users need enough filters to find the right trip, but the interface cannot feel like a database. I built the browsing layer around simple decisions: where do you want to go, what kind of activity do you want, and how do you want to sort the options.
The booking flow also required careful state handling. The app has to remember the selected listing, date, guest count, calculated total, payment step, generated confirmation reference, and local booking history. If any part of that flow feels broken, the marketplace loses trust.
The final challenge was credibility. Adventure travel involves safety, trust, and local operators. I designed each listing to show signals such as verified operator status, ratings, reviews, group size, difficulty, itinerary, inclusions, and exclusions. The goal was to make the user feel informed before they click book.
What I learned
Building Trailsmate taught me that marketplaces are really trust systems.
The technical work is not only about rendering cards or storing bookings. The product has to reduce uncertainty at every step. A traveler needs to know what the trip includes, who runs it, how hard it is, how much it costs, and what happens after payment.
I also learned how much value can come from a clean shared data model. Once listings, destinations, operators, and bookings are structured well, the same data can power discovery, filters, detail pages, price logic, recommendations, and confirmed trips.
On the engineering side, Trailsmate helped me practice state driven UI, derived catalog results, client side routing, local persistence, booking flow logic, responsive design, and marketplace style product architecture.
What is next
The next version of Trailsmate could add real operator dashboards, operator onboarding, live payment integration, a server side booking API, user accounts, reviews and ratings, map based discovery, WhatsApp booking notifications, availability calendars, and real time inventory.
The long term vision is to make Trailsmate the trusted adventure layer for Maharashtra. Travelers should be able to open one product, discover what is possible this weekend, compare verified local operators, and book with confidence.
Built With
- css
- github
- html
- javascript
- localstorage
- oxlint
- postcss
- react-19
- tailwind-css-3
- vite-8
Log in or sign up for Devpost to join the conversation.