Why I'm Building Trip Tools

There are lots of good tools for managing trips. That's the problem.

TripIt parses confirmation emails. Tricount handles expense splitting. Google Maps knows where everything is. Each tool does its job well. But none of them talk to each other, and none of them understand that all of this activity is part of the same trip. The burden falls on me (and you) to juggle them all: cutting and pasting, multiple logins, different formats. Planning with others makes it worse - now everyone has their own separate research scattered across their own apps.

I've been planning trips for a long time and have invested in refining my methods: custom spreadsheets, map templates, scripts to manage data. It's more than the average person would want to do, and it's still a mess.

The Insight: Locations Bind Everything

After years of this, I realized what ties a trip together: Locations.

Every phase of trip planning revolves around places. The museum you want to visit. The hotel you're considering. The restaurant someone recommended. The airport you'll fly into. During research, you're gathering Locations. During planning, you're comparing and prioritizing them. During booking, you're reserving access to them. During the trip, you're navigating between them. When writing your journal afterward, you're writing about them.

If Locations are the organizing principle, then a trip tool should treat them as first-class objects that connect to everything else - not as pins on a map disconnected from your itinerary, bookings, and memories.

This is the core idea behind Trip Tools: one place for the entire trip lifecycle, with Locations to bind it all together.

The Trip Lifecycle

A trip isn't just "planning." It's a continuous thing that can span months (years?):

Research and Planning - Gathering places of interest, comparing options for lodging and transportation, deciding what's worth the time. Right now this lives in browser tabs, bookmarks, notes, and half-remembered conversations.

Booking - Converting decisions into reservations. Tracking what's booked versus what still needs booking. Managing confirmations, costs, cancellation deadlines, and who paid for what.

Execution - Actually traveling. Referencing all that planning and booking data. Knowing where you're going, when things are open, what you've reserved.

Memory - Writing about the trip, organizing photos, sharing with others. Connecting what you experienced back to the places you visited.

Each phase builds on the previous one. But our tools treat them as if they exist in isolation.

What I'm Building

Trip Tools is my attempt to build what I wish existed. Here's the vision:

Locations - Every place associated with a trip, organized and enriched. Not just pins, but places with notes, categories, links to related bookings, and context about why they matter. The foundation everything else connects to.

Planning - A structured way to research and compare options before you commit. Track candidates for lodging, transportation, activities. Add custom attributes for comparison. See what's decided versus what's still open.

Itineraries - Day-by-day schedules that connect to your locations and bookings. Bookings appear automatically. Changes stay synchronized. Clear visibility into what's confirmed versus what's still tentative.

Bookings - The financial and logistical layer. What's booked, what still needs booking, what it cost, who paid, when the cancellation deadlines are. Connected to the itinerary so you can see your trip as a whole.

Journal and Travelog - Where memories live. Write about your trip with rich text and your photos. Reference your locations, see the context of your itinerary. Publish as a shareable travelog for friends and family.

The key is connection. Your journal entry about that restaurant links to the location, shows photos from that day, notes what you spent. The trip is the organizing principle, not an afterthought.

Where We Are Now

I've started with two pieces: the journal and a browser extension for managing locations.

Journal and Travelog

I started here because this is where my personal pain was most acute - two years of trip notes and photos I hadn't organized. The journal feature lets you write rich travel entries with drag-and-drop photos, auto-save, version history, and publishing as shareable travelogs. It works. I'm using it for my own trips.

Browser Extension

For visual planning, I use Google My Maps to plot locations. It's capable but clunky, and all the data lives trapped inside Google. The browser extension bridges this gap: use GMM for visual plotting while keeping your location data synced to Trip Tools, where it can connect to everything else.

These are the first two pieces. The planning and itinerary features are next.

Why Open Source

I'm building Trip Tools as an open source project because travel tools should work for travelers, not for ad revenue or data harvesting.

The business model for most travel apps is advertising, affiliate commissions, or selling your data. That creates incentives that don't align with what users need. I'd rather build something useful and let people who find it valuable contribute - code, design feedback, or just telling me what would make it work for their trips.

This also means you can self-host if you want to keep your travel data private.

What's Next

The near-term roadmap:

• Planning - Structured comparison of options before booking. The "candidates" workflow that no current tool handles well.
• Itineraries - Day-by-day schedules that connect locations, bookings, and activities.

These will roll out over the coming months as I build them, test them on my own trips, and iterate based on feedback.

If this resonates - if you've felt the same frustration with trip fragmentation - I'd like to hear from you. The project is on GitHub, and I'm looking for early users willing to try it and share how they plan trips.