Written by Piotr Kuczyński with Claude (Anthropic) as writing tool.
I’ve been building an AI travel app on the side. That might seem odd for someone who advises enterprises on AI transformation. But it’s precisely because I advise that I build.
Building an AI product taught me more about why enterprise AI fails than advising on a dozen.
Here’s what I learned — and why it applies to your organization.
The Problem I Set Out to Solve
Family trip planning is a mess. Forty browser tabs. Screenshots in a shared album. A spreadsheet that no one updates. Arguments about which day to visit what.
I wanted a tool that would:
- Let us dream about destinations together
- Help us plan without the tab chaos
- Actually work during the trip when plans change
Simple, right?
The Sprawl Begins
Within weeks, I had:
- A chat interface with streaming responses
- Location validation against Google Places
- Weather integration
- A trust hierarchy for AI-generated suggestions
- Markdown rendering
- User profiles
- Trip sharing
- A “Trip Wrapped” summary feature
I was building a platform. I’d forgotten I just wanted to plan a family trip to the Azores.
The First Structured Discussion
I staged a debate. Product strategists, UX specialists, skeptics — all simulated through AI, but structured as a real panel with clear questions and a facilitator.
The question: What is the core experience, and what can wait?
The answer was uncomfortable: almost everything could wait except the chat-first planning experience. The weather integration, the trust badges, the sharing system — all valuable, but not the thing that would determine if the product worked.
I cut. For the first time, I cut before building, not after failing.
The Six Philosophies That Emerged
Over 7 deep discussions and 14 shaped bets, a set of principles crystallized. Not principles I invented — principles I discovered through the debates.
1. Chat-First, Not Structure-First
The original design had a timeline on one side, map in the middle, chat squeezed into a corner. The insight: people don’t plan trips by staring at empty timelines. They plan by talking.
The lesson: Most AI tools force users to translate fuzzy intentions into structured data upfront. The system should meet them where they actually think.
2. Seduce Before You Ask
Most onboarding is interrogation. “Where? When? Who?” feels like paperwork.
TripForge delivers value before commitment. Explore destinations without signing up. Browse sample itineraries. Get AI insights instantly. Signup gates the action, not the exploration.
The lesson: Interest should be free. Action requires commitment. Your internal AI tool’s first experience shouldn’t be configuration.
3. Trust as a Design Problem
AI hallucinations are real. Users know this. “Trust the AI” doesn’t work.
TripForge shows its work:
- Trusted Spot — Featured in multiple real trips
- Manually Curated — Human-reviewed
- AI-Verified — Cross-checked against sources
- Unvalidated — Pending verification
The lesson: Transparency about uncertainty builds more trust than false confidence. Don’t hide complexity — make it comprehensible.
4. AI Proposes, Human Decides
Throughout the product, the tone assumes collaboration:
- “Here are alternatives from your location pool”
- “I noticed you saved this place — want to add it?”
- “Heavy rain forecast — indoor alternatives attached”
The lesson: The future of AI products isn’t “let the AI decide.” It’s “let the AI propose and explain.” Users feel agency because they actually have it.
5. Constraints Clarify, Don’t Limit
The location pool provides pre-vetted alternatives without paralysis. Limiting choices to validated options increases confidence.
The lesson: Good AI products aren’t about unlimited options. They’re about understanding intent deeply enough to present the right options with visible reasoning.
6. Three Modes, One Consistent Voice
Users have different needs at different times:
- Dreaming (weeks out) — Chat-led exploration
- Planning (days out) — Hybrid chat + structure
- Traveling (during trip) — Map + quick adjustments
The chat is the consistent thread. Interface changes, but users always talk to the same assistant.
The lesson: Instead of separate tools for different phases, one AI maintains context across the user’s journey.
The 80 Commits
The git history tells the story of iteration:
Initial setup → location validation → weather integration →
actionable chat → mobile responsive → place validation →
markdown support → ratings → Trip Wrapped → metrics foundation
But what the commits don’t show is what didn’t get built. The features that were shaped and then scoped out. The ambitious ideas that became “not this bet.”
The discussions made the edits possible. Each cut was validated by a structured debate, not by gut feel.
What This Means for Enterprise AI
Every principle I discovered building TripForge applies directly to enterprise AI initiatives:
| TripForge Principle | Enterprise Translation |
|---|---|
| Chat-first | Meet users where they think, not where your data model lives |
| Seduce before you ask | Demonstrate value before demanding process change |
| Trust as design | Make AI reasoning visible; don’t hide uncertainty |
| AI proposes | Human-in-the-loop isn’t a limitation; it’s the product |
| Constraints clarify | Fewer, better options beat infinite configurability |
| One voice | Consistent AI experience across the user journey |
The Thesis, Revisited
TripForge isn’t a travel app. It’s a proof point.
It proves that structured discussions create the editing function solo builders lack. It proves that the same principles that make consumer AI products work also apply to enterprise contexts. It proves that building keeps you sharp in ways that advising alone cannot.
This is what it looks like when someone who actually builds AI products applies human-centered thinking.
Next: Episode 3 — The Test. Rebuilding my oldest failed project with everything I learned.
Attribution
The TripForge journey included structured discussions with AI-simulated perspectives drawing on frameworks from product leaders, content strategists, positioning experts, and methodology thinkers. The method described here — orchestrating multi-perspective debates to arrive at insight no single viewpoint can reach — is what the Laboratory practices.