TrailsMate — Maharashtra Adventure Booking Platform

Inspiration

Every weekend, thousands of people in Mumbai and Pune search WhatsApp groups, Instagram pages, and scattered websites trying to find a reliable trekking group or a campsite that won't cancel last minute. The adventure tourism space in Maharashtra is massive — but completely fragmented. There's no single platform where you can discover, compare, and book verified outdoor experiences with confidence.

We saw this gap and thought: what if booking a Sahyadri trek was as simple as booking a movie ticket? What if every operator was verified, every itinerary transparent, and every payment secure?

That question became TrailsMate.

What it does

TrailsMate is a full-stack adventure booking marketplace for Maharashtra that connects travelers with verified local operators. Here's what it delivers:

For Travelers:

• Browse curated experiences across trekking, camping, water sports, paragliding, rock climbing, and more
• Filter by activity type, difficulty level, price range, destination, and ratings
• View rich detail pages with full itineraries, inclusions/exclusions, operator profiles, and real reviews
• Book experiences with secure Razorpay payment integration (real test-mode transactions)
• Manage bookings — view upcoming trips, download receipts, cancel with refund tracking
• Submit reviews after completing an experience

For Operators (via Admin):

• Full admin dashboard with real-time booking stats, revenue tracking, and experience management
• View all bookings with search, status filtering, and CSV export
• Manage users and verified operator listings
• Monitor contact form submissions from travelers

The Platform:

• Real payment processing via Razorpay (order creation → checkout → server-side signature verification)
• JWT-based authentication with bcrypt password hashing
• Session persistence across page refreshes
• Mobile-responsive design that works on every screen size
• Deployed live on AWS Amplify with connected backend

How we built it

Architecture Decision: We chose Next.js 14 (App Router) as a full-stack framework — it gives us React for the frontend AND serverless API routes for the backend in a single deployment. No separate backend server to manage.

Tech Stack: | Layer | Choice | Why | |-------|--------|-----| | Framework | Next.js 14 | SSR + API routes in one deploy | | Language | TypeScript | Type safety across full stack | | Styling | Tailwind CSS | Rapid, consistent UI | | State | Zustand + localStorage | Lightweight, persists across refresh | | Auth | JWT + bcrypt | Stateless, secure, no third-party dependency | | Payments | Razorpay SDK | Indian market standard, test mode available | | Icons | Lucide React | Clean, consistent iconography | | Deployment | AWS Amplify | Auto-build from GitHub, SSR support |

Data Flow:

1. User browses → Client reads from data layer (experiences, destinations)
2. User registers → POST /api/auth → bcrypt hash → JWT token → stored in localStorage
3. User books → POST /api/payments/create-order → Razorpay creates real order → Checkout popup opens → User pays with test card → POST /api/payments/verify → Server validates HMAC signature → Booking confirmed
4. Booking persists in client store → Shows in "My Bookings" and Admin panel

Design Philosophy:

• Green primary palette (nature/adventure association)
• Card-based layouts with hover micro-interactions
• Progressive disclosure — don't overwhelm, reveal details on demand
• Mobile-first responsive breakpoints

Challenges we ran into

1. Razorpay Integration Complexity Getting the three-step payment flow right (create order → client checkout → server verify signature) required understanding HMAC-SHA256 signature verification. The Razorpay popup also needed dynamic script loading and proper callback handling for success/failure states.

2. State Persistence Without a Database For a hackathon timeline, spinning up a full database felt like overkill. We engineered a hybrid approach: server-side in-memory DB for API operations + client-side localStorage persistence for session data. This means the app works perfectly for demo purposes while being architecturally ready for a real database swap (the db.ts abstraction layer makes this a one-file change).

3. Next.js SSR + Client State Zustand stores are client-side, but Next.js pre-renders pages on the server. We had to build a hydration system (Providers.tsx + store.hydrate()) that gracefully loads persisted state after mount without causing hydration mismatches.

4. AWS Amplify Deployment Connecting GitHub → Amplify with environment variables, SSR compute configuration, and proper build settings required careful orchestration. The amplify.yml build spec needed exact configuration for Next.js standalone output mode.

Accomplishments that we're proud of

• Real payments work. Not a mock, not a simulation — Razorpay test mode processes actual orders with signature verification. Judges can make a real test payment and see it confirmed.

• End-to-end booking flow. From discovery → filter → detail → date selection → guest info → payment → confirmation → receipt download → cancellation. Every step is functional.

• Admin panel. A complete management interface with dashboard stats, booking management, CSV exports, user listings, and contact message monitoring. Not just a frontend — a real operational tool.

• Production architecture. TypeScript types, clean API contracts, proper error handling, input validation, and a separation between catalog data and user-generated data. This isn't throwaway hackathon code — it's structured for growth.

• Deployed and live. Not just a localhost demo. Fully deployed on AWS Amplify with environment variables, automated builds from Git, and a public URL anyone can visit.

What we learned

• Razorpay's SDK is well-designed but the documentation assumes familiarity with payment flows. Building the order-verify loop from scratch taught us how payment integrity works at a protocol level.

• Next.js App Router is powerful but opinionated. Server Components, client boundaries, and the interplay between static generation and dynamic routes required careful thinking about where state lives.

• Design matters as much as code. We spent significant time on micro-interactions, hover states, gradient overlays, and typography hierarchy. The difference between "looks like a hackathon project" and "looks like a product" is in these details.

• Startup thinking shapes engineering. We approached this as founders, not just developers. Every feature decision was filtered through: "Would a real user in Pune searching for a weekend trek actually need this?"

What's next for TrailsMate

Immediate (Post-Hackathon):

• Connect Supabase PostgreSQL for persistent multi-user data (auth, bookings, reviews)
• Add Google OAuth and phone OTP login via Supabase Auth
• Real email notifications (booking confirmation, cancellation alerts) via AWS SES
• Image uploads for reviews and operator galleries via S3/Cloudinary

Growth Features:

• Operator self-service portal — let operators list and manage their own experiences
• Dynamic availability calendar with real-time slot management
• Group booking discounts and coupon system
• Weather-aware recommendations (integrate IMD data for monsoon trek advisories)
• Traveler profiles with achievement badges and trip history

Platform Expansion:

• Flutter mobile app — the component architecture and API-first backend are designed to support a native mobile client. The REST APIs (/api/experiences, /api/bookings, /api/auth) are already mobile-ready with proper JSON contracts, pagination, and error handling. A Flutter frontend would plug directly into the same backend.
• Expand beyond Maharashtra — Goa, Karnataka Western Ghats, Himachal Pradesh
• Multi-language support (Marathi, Hindi, English)
• Operator analytics dashboard with booking trends and revenue forecasts

---

Built with ❤️ for Maharashtra's mountains, rivers, and the adventurers who explore them.

Built With

• amazon-web-services
• javascript
• python