Where It Started

We all travel our whole lives, and the pieces end up everywhere: booking emails, PDFs, screenshots, photo rolls, notes apps and half-remembered recommendations from friends. Years later you want to know why that hotel was so bad, which restaurant you swore you'd go back to, or whether a place is worth repeating, and the answer is gone.

I wanted one place for all of it. Not a planning tool that forgets the trip once it's over, but a diary that grows with every journey: the bookings, the notes, the photos, the ratings and the stories, plus a view of my whole travel life that makes me want to go somewhere new.

What It Does

• One home per trip: flights, train rides, rentals, stays, restaurants, places and experiences, shown as tabs with a day-by-day itinerary, a diary, a photo wall and a map of everywhere you went.
• A globe that fills in: the home screen shows every city you've visited on a 3D globe, next to statistics that are drawn rather than just counted: days away, countries, cities and trips.
• Bookings that fill themselves in: drop in a PDF, a photo of a ticket, a web page or a Google Maps link, and the form completes itself. A boarding pass can even start a whole new trip.
• Recommendations that survive: the tips people give you before you go are kept per trip with the reason behind them, and one tap turns a tip into a real entry.
• A trip planner grounded in real places: suggestions come from a database of real venues, so the AI can't invent a restaurant that doesn't exist.
• Made for sharing: trips can be shared with travel companions, expenses split and settled, and the web version installs like an app on any phone.

How I Built It

I built TripsTracker on my own with Claude Code, from the first sketch to the live app, in about three months: 319 commits across 39 days of actual building.

• One codebase, two platforms: it runs as a native iOS app and as a website from the same code, using Expo and React Native. Where the two need to differ, a web version of a screen sits right next to the native one instead of splitting into a separate project.
• A real backend: Supabase handles the database, sign-in and private photo storage. Every table has row-level security, so each person can only ever see their own trips and the ones shared with them.
• AI where it saves time, with guardrails: booking extraction tries a fast, cheap model first and only falls back to a stronger vision model when it has to. The trip planner gets real places from a venue database and is only allowed to answer with places from that list, and a set of checks decides whether to trust each answer. Usage limits per person keep the costs predictable.
• Spec first, then code: every feature started as a written spec (21 of them) before a single line was built. That kept a big app coherent, even though it grew one evening at a time.
• Small, honest tests: the logic that matters, like totals, splits and the planner checks, lives apart from the screens and is covered by simple self-checking scripts.

What I Learned

Building a product end to end is a different discipline from building a feature. I had to decide what not to build, design every screen, model the data so six very different kinds of entries could live in one place, and make AI useful without letting it make things up. It also showed me how far one person can go with the right AI workflow, as long as the specs, the structure and the judgement stay human.

What's Next

Opening it up to more travellers, polishing the iOS release, and making the statistics even more fun to explore.

Tech Stack