Building Trip Globe: An Experiment in AI-Driven Development

People talk about AI coding tools being a SaaS killer — one person shipping what used to take a team. I'd been using Claude Code at work and noticed the shift myself: my time was moving away from implementation and toward design, planning, and validation. Features that used to take a weekend now took an evening. Testing became something I actually enjoyed — fast enough to be rewarding instead of tedious.

I wanted to see what that looked like on a real end-to-end project. Not a work task where the product decisions are already made, but something where I own everything: the vision, the architecture, the design, the roadmap. How quickly could one person turn a side project into a real product?

I had a dormant D3.js project sitting around — an interactive 3D globe where you click countries to mark them as visited. It looked cool, but that's about all it did. No dates, no trip names, no stories. Just colored shapes on a sphere.

Trip Globe became the experiment.

Why this project

Travel is personal to me. I get it from my parents, who took me all over the world as a kid — South Africa, Mount Bromo in Indonesia, a sunset at Angkor. Those are some of my strongest memories, and I cherish them.

A travel log that keeps a trace of those moments — a place to find them again — matters to me. Not a photo dump or a location history, but something built around memories. Something personal, something for you.

What I built

Two weekends. That's roughly how long it took to go from the static globe to what exists today:

• Multi-user app with Google OAuth. Sign in, create your profile, set a username.
• Trip-centered data model. Each trip has a name, dates, one or more stops (city + country), and notes. The globe, the stats, the timeline — they're all visualizations of the same trip data.
• Photo storage. Up to 3 photos per stop, curated not dumped. The logbook should feel like a highlights reel, not a camera roll.
• Public profiles. Each user gets a shareable URL like globe.pierreschutz.com/pierre with their globe, trip count, country stats, and recent trips. Private by default, public by choice.
• Mobile-responsive. Works well on phones with native-feeling navigation, quick trip creation, and touch interactions on the globe.

All from a single-page globe that couldn't even store a trip name. Here's how.

How I build with AI

The most surprising thing about working with AI coding tools isn't the speed. It's the role shift.

When Claude Code writes the implementation, I stop thinking like a developer and start thinking like a product manager. I'm not in the code deciding how to structure a function or which CSS property to use. I'm thinking: what should this feature actually do? What does the user see? What's the flow? Does this feel right? It's counterintuitive, but removing myself from the code makes me better at the product. I have more mental space for the decisions that actually matter.

The workflow has a rhythm to it. I start by planning — writing design docs, feature specs, deciding what to build based on what the product needs, not what's technically easy. I use Claude to help me think through product decisions before touching code. Then I describe what I want, and Claude implements it across however many files it touches. It understands the module structure, follows existing patterns, and runs the tests. I review the output, test it myself, push back on anything that doesn't feel right. This is where product taste matters more than technical knowledge.

One unexpected side effect: I test way more than I used to. When writing tests is fast and painless, you actually do it — and the codebase is better for it.

The meta-game is tooling. Every time I do something useful in a session, I ask Claude to write a skill for it — a reusable workflow I can invoke next time. I build hooks, skills, and custom workflows that make future features ship faster. The compounding effect is real. Each feature is easier than the last because the tooling around it is better.

The stack matters here too. About 15 vanilla JS modules, each responsible for one thing. No framework overhead, no state management boilerplate. It's complex enough to be a real project — auth, real-time data, file storage — but simple enough that Claude can understand any module and make changes without fighting abstractions. The feedback loop stays tight: describe what you want, see it working, iterate.

What's next

The closest thing to what I'm building is Polarsteps — route tracking, notes, and printed travel books, backed by a team of ~100 people and a decade of development. I'm deliberately treating Trip Globe like a real product. Not because I think it'll be the next Polarsteps, but because that's the experiment. I want to see what happens when you apply real product thinking — user research, prioritized roadmaps, shipping cadence — to a side project where AI handles the heavy lifting.

The roadmap has followers (one-way, request/approve — see when friends log new trips), achievements (milestones like "10 countries" or "4 continents"), quick capture (log a trip in 30 seconds, enrich later), and analytics to understand how people actually use the app.

Before AI tools, this is where a side project would stall. You'd build the core feature, maybe one more thing, and the effort-to-progress ratio would kill your motivation. But when the calculus changes — when you can actually follow through on a roadmap — you start asking a bigger question: what does "solo developer" mean when your tools are this capable?

I don't know the answer yet. I'll keep building and find out.

Side projects start from a personal itch. Sometimes they turn into real products. More often, the value is in the building itself — you reinvent the wheel because you want to understand how wheels work. Maybe I'll write another post in a year about where this ended up.

Try it

The app is live at globe.pierreschutz.com. You can browse my profile at /pierre to see what it looks like with real data. Sign in with Google to start your own logbook. Fair warning: there will be bugs — it's a side project, and I'm shipping fast.