Building TravelMate: Part 1 — Why I Built a Social Travel Platform (And Why My Last Project Failed)

ALISAM SRIVARDHAN — Sun, 30 Aug 2026 23:52:49 +0000

This is Part 1 of a 4-part series documenting the build of TravelMate, my 3rd-year engineering project. Part 2 covers architecture and tech decisions, Part 3 dives into the hardest engineering problems I solved, and Part 4 (coming after the project ships) covers what I learned.

The project that didn't make it

Last year, in my 2nd year, I tried to build something called LexAssist. I don't talk about it much, because it didn't really go anywhere — not because the idea was bad, but because I made almost every mistake a student developer can make on a solo project. I added features before the core worked. I didn't think through the architecture before writing code. Security was an afterthought I kept meaning to "add later." By the time the project deadline arrived, I had a folder full of half-working pieces and no coherent story to tell about any of it.

It wasn't a fun feeling, explaining in a viva why half the features were "still in progress."

So when it came time to pick my 3rd-year project, I made myself one promise before I wrote a single line of code: a complete, working, secure application beats a huge, half-built one, every single time. That sentence became the actual first line of my project brief, and I've tried to hold myself to it through every phase since.

The problem I actually wanted to solve

I travel occasionally with friends, and every time a trip comes together, the same mess happens. Someone starts a WhatsApp group. Someone else makes a spreadsheet for expenses that nobody updates. The itinerary lives in a Google Doc that three people have different edit access to. And before any of that — the actual hardest part — is just finding people who want to go to the same place, at the same time, with a similar budget and vibe.
_
That last part is the real problem. Booking a hotel or a train ticket is a solved problem — a dozen apps do it well. But _finding your people — other travelers who want roughly what you want, and then actually coordinating with them safely — isn't something any single app handles well. You end up stitching together a search, a group chat, a spreadsheet, and a prayer.

That's the gap TravelMate is trying to fill:

"Find people who want to take a similar trip, and help them safely form, plan, coordinate, and manage that trip together."

Not a booking engine. Not another generic social app. A platform built specifically around one core idea: compatibility-based travel group formation.

What that actually looks like

Imagine you type in: Goa, from Hyderabad, December 20–24, budget ₹8,000, interested in adventure and beaches, prefer trains.

Instead of just showing you hotel listings, TravelMate should:

Find existing trips that match what you're looking for
Find other travelers with similar plans and preferences
Calculate how compatible you actually are with a given trip or group
Let you request to join, and help the group form
Once you're in, give your group a private space to plan everything together — chat, a shared itinerary, polls for decisions, and expense splitting

That whole loop — discovery, matching, group formation, collaborative planning, safety, and post-trip memories — is the actual product. Not a single feature, but the connective tissue between all of them.

Why this needed to be more than a CRUD app

It would have been easy to scope this down into "a place to post trip listings" — basically a bulletin board. That's a weekend project, not a 3rd-year flagship. I wanted this project to actually demonstrate real software engineering: a genuine compatibility-scoring algorithm (not just filters), real-time features that need actual security thinking (chat rooms that can't leak into each other), concurrency problems that are real distributed-systems concepts wearing a travel-app costume (what happens when two people grab the last seat on a trip at the same instant?), and — because the whole point of "find people to travel with" involves meeting people you don't know well — a genuine safety layer, not a bolted-on afterthought.

That's also why, unlike LexAssist, I didn't start by writing code. I spent what felt like an unreasonably long time just on Phase 0 — architecture, database design, API design, security model, before touching a single controller. It felt slow. It was worth it. Every phase since has built cleanly on top of the last one, because the foundation was actually thought through instead of improvised.

What's coming in this series

In Part 2, I'll walk through the actual architecture decisions — why a modular monolith instead of microservices, how I designed the database schema (and the specific, recurring decision of when to embed data versus reference it, which came up constantly), and the tech stack choices and why each one earned its place instead of just being "what everyone uses."

Part 3 is the part I'm most excited to write, because it's where the real engineering lives: a greedy algorithm for settling group expenses with the minimum number of transactions, a rule-based compatibility engine using HashSets and a Min-Heap for efficient Top-K matching, and the very deliberate security work behind real-time chat — making sure a Socket.IO room can't be joined by someone who was never actually invited.

Part 4 will come once the project is further along — the honest version, including what broke, what I had to redo, and what I'd do differently.

For now: the idea is set, the architecture is built, and the first several phases — auth, profiles, trips, discovery, matching, group formation, real-time chat, collaborative planning, and a working AI trip planner — are done and tested. LexAssist taught me what not to do. I'm hoping TravelMate is the proof that the lesson actually landed.