Travelore wasn't born from market research, startup trends, or some brilliant business insight.
It started with a trip to Mussoorie.
During my first semester at IIT Roorkee, I went on a trip with friends. It was one of those experiences that makes you realize how much there is to explore outside the classroom.
After coming back, I wanted to travel more.
The problem was simple.
My friends were busy.
Some had club work. Others had academics, competitions, or personal commitments. Even when people wanted to travel, coordinating schedules was difficult.
Looking back, I had another problem too.
I was comfortable with my existing friend circle.
I wanted to travel, but I didn't really want to step out of my comfort zone and find new people. As a result, I spent months wanting to explore places while not actually going anywhere.
Eventually I realized something.
There were probably many students facing the same issue.
People wanted to travel but didn't know who to go with.
The Accidental Beginning
A few months later, I built CampusSphere, a map-based social application for IIT Roorkee students.
While working on it, I added a small feature almost as an afterthought.
Students could create a trip card, add their destination, leave contact information, and find travel buddies.
It wasn't sophisticated.
There were no fancy matching algorithms.
No recommendation systems.
No AI.
Just a simple way for people to say:
"I'm going here. Anyone interested?"
At the time, I didn't think much of it.
It was just another feature.
The Unexpected Feedback
After launching CampusSphere, I showed it to some of my school friends.
The funny thing was that CampusSphere was built specifically for IIT Roorkee students. My school friends couldn't even use most of the application meaningfully.
So when they explored it, I expected them to find the map feature interesting.
Instead, several of them pointed out the travel buddy feature.
"That's actually pretty cool."
That response stuck with me.
When people who aren't even your target audience independently point to the same feature, it's usually worth paying attention.
For the first time, I wondered:
What if the travel feature was the product?
Learning Before Building
Around the same time, I wanted to learn Next.js.
Everyone seemed to be using it, and it felt like the framework I should know if I wanted to build modern web applications.
The problem was that I had no idea where to start.
So I did what most students do.
I watched tutorials.
I followed Hitesh Choudhary's Next.js content and built a tutorial project from scratch. More importantly, I finally started understanding how modern full-stack applications actually worked.
Authentication.
Databases.
Routing.
File uploads.
Server-side rendering.
Things that previously felt magical started making sense.
Building Travelore
After my third-semester exams ended, I sat down to build Travelore.
This time my goal wasn't speed.
My goal was learning.
I deliberately avoided relying heavily on AI.
Instead of asking for complete solutions, I wanted to understand why things worked.
So I spent days reading documentation, fixing bugs, breaking things, and rebuilding them.
Sometimes progress was fast.
Sometimes I would spend hours solving what looked like a tiny issue.
I even took breaks in between when I went out and traveled myself.
In total, it took roughly nine days of focused work to build the first functional version.
The stack was completely new to me:
- Next.js
- Prisma
- PostgreSQL
- NeonDB
- Clerk Authentication
- Cloudinary
Every feature felt like a small victory.
Solving Trust
One of the biggest challenges wasn't technical.
It was trust.
Traveling with strangers is fundamentally different from interacting with strangers online.
People need confidence that the other person is real.
That's why one of the earliest features I implemented was college email verification.
Users could verify themselves through their college email, create a profile, post trips, and send requests to join others.
The idea was simple.
You might not know someone personally, but knowing they're a verified student from a real college makes the interaction feel significantly safer.
The Launch
When I returned to campus for the next semester, I tested the application with a few friends.
Once the core functionality felt stable enough, I shared it across college WhatsApp groups, just like I had done with CampusSphere.
The results were very different.
Around twenty people signed up.
A year earlier, CampusSphere had crossed 400 users in less than a day.
Travelore didn't.
At first glance, that sounds like failure.
But the reality was more complicated.
CampusSphere benefited from perfect timing, curiosity, and a mandatory signup flow.
Travelore launched during a completely different phase of the academic year. Students weren't curious about a new platform anymore. There was no forced registration. Users could browse without immediately creating accounts.
The product was also solving a much harder problem.
Finding travel companions is not the same as reading funny comments on a campus map.
One requires commitment.
The other requires curiosity.
What Travelore Really Gave Me
Travelore never became a viral success.
But that wasn't the most important outcome.
The project taught me how modern web applications are built.
It taught me how to read documentation instead of searching endlessly for tutorials.
It taught me patience.
Most importantly, it taught me that building products starts with paying attention to small frustrations in your own life.
Travelore wasn't created because I wanted to learn Next.js.
I learned Next.js because I wanted to build Travelore.
That's a subtle difference, but it changed the way I think about projects forever.