Tildenn

Solo-built AI travel planner using GPT-3, hierarchical clustering, and custom rule engines. 100 DAU. One of the earliest AI consumer products in the travel space (2022).

In 2022, I built one of the earliest AI travel planners. GPT-3 had just opened to developers, global travel was exploding back post-COVID, and I was living in Thailand watching both happen in real time.

The problem was personal. I’d been to 22+ countries by graduation and planned every single trip the hard way. Spreadsheets, 10 browser tabs, hours of Googling. One person always does all the work while everyone else just shows up. After 50+ interviews with other travelers, I confirmed it wasn’t just me.

But here’s what made it interesting technically: GPT-3 couldn’t actually plan a trip. It hallucinated places, invented addresses, had no concept of distance or timing. You couldn’t just wrap the model in a UI and ship it. So the real question became: how do you build a system that’s smarter than the model it’s built on?

I’d always been drawn to products that bridge digital intelligence with real places. Foursquare, Ingress, Pokemon Go. That lineage. And as an admin of Discord Travelers and a Level 7 Google Maps Local Guide, I had both the community and the obsession to try.

The system I built was hybrid by design. GPT-3 handled natural language input and ideation, but the actual itinerary logic ran through a decision-making ruleset I built independently of the LLM. Hierarchical clustering with haversine distance grouped activities by proximity. Type-aware rules prevented back-to-back restaurants and balanced categories across days. Every suggestion got validated against Google Places API and Mapbox to confirm the place exists, is open, and is reachable.

That last part was harder than it sounds. Places API gives you raw data, not relevance. Ask it for “interesting things near Shibuya” and you might get a gas station. I had to engineer queries that returned culturally relevant, non-generic results. This was context engineering before anyone called it that. Before MCP, before RAG, before any of the frameworks we have now.

And then there were timezones. You wouldn’t expect something as fundamental as “when is this place open” to be one of the hardest problems, but dealing with dates across locales is genuinely painful. The ISO 8601 standard is convoluted, and when you’re building a travel product that spans multiple countries and timezones, every assumption breaks. date-fns saved me repeatedly, but I still found myself fixing timezone bugs when I least expected them. Localization and internationalization aren’t afterthoughts in a travel product. They’re the product.

The algorithm ran on Lambda functions. The main app was Next.js with MongoDB. The key insight was simple: use the right tool at the right time. Transformers for language. Classical ML for spatial clustering. Rule engines for constraints. The AI wasn’t the product. The system was.

You can’t ship a transformer as a product. You ship the system around it that makes the output trustworthy.

The product itself had three synchronized views I built from scratch: a calendar, a map, and an agenda. All in sync. Drag something on the calendar and it moves on the map. The AI re-optimizes around your changes. The design philosophy was that the system does the heavy lifting but the human stays in control.

This took many iterations. The target user was specific: not the resort lounger, but the hyper-adventurer who wants to spend every waking minute immersed in culture. The person who needs a system as ambitious as they are.

I built the whole thing solo over two years from Thailand. No team, no funding. It reached about 100 daily active users. People loved the experience, but the business model never clicked. Affiliate monetization couldn’t sustain growth and direct charging was a hard sell when people are conditioned to plan trips for free.

I sunset it to pursue Blue Origin. But the 0-to-1 of doing user research, system architecture, ML pipelines, product design, and growth as one person? That’s the foundation everything after was built on.

The hardest part of a solo build isn’t the code. It’s making every decision yourself and living with all of them.