Senior Product Leader · Travel Technology & AI
Twenty years building the systems that run the travel industry. Last five months building something new on my own.
In April 2025 I published an article on the evolution of travel technology. A European VC read it and reached out. That conversation turned into a question I couldn't stop thinking about: if AI is going to transform travel, what's actually in the way? I gave myself five months to find out. Veyant is what I built.
Now looking for the right next thing. Senior product, strategy, or partnerships roles where independent thinking and deep domain knowledge both matter.
Where It Started
From GDS to My Travel Data Cube · Published on Iterative Livings, 2025
The article traces every wave of travel technology — from GDS to NDC to AI — and makes the case that the next wave is not a better search interface. It is AI that acts on your behalf. It generated inbound from industry colleagues and a European VC investor, and the question it raised became Veyant.
What I Built on My Own
Five months · 2025–2026 · Solo builder path
The seed was older than the five months. On a flight from Singapore to LAX in 2023, I watched a plane full of exhausted travelers fumble with apps trying to book ground transportation after midnight, each one solving the same problem alone. I sketched a concept on a napkin: what if one trusted data layer knew your preferences, your loyalty status, your calendar, and could act on your behalf? The VC conversation in 2025 pulled that question back out.
The thesis I wanted to test: AI agents can already reason about travel, but they can't actually do anything useful because they don't have context. No access to loyalty accounts, no awareness of corporate policy, no connection to supplier systems. The intelligence is there. The infrastructure isn't.
I approached it the way I'd approach the first months of any senior PM role on a hard problem. Research first. Then architecture. Then working artifacts.
What I learned over five months:
The problem is real and larger than I thought. Travel Management Companies handle 83% of tickets manually at $20 or more per ticket, not because the work is complex but because the systems don't talk to each other.
The solution needs to be infrastructure, not another app. I designed a three-domain architecture: a Personal Cube for loyalty status and preferences, a Corporate Cube for policy rules and approvals, and a Supplier Cube for airline and hotel connectivity. A traveler would own this context independent of any booking channel.
I built a proof-of-concept to make it tangible. A front-end demo that shows what the experience would feel like across two scenarios, and a working MCP server that exposes three enterprise travel capabilities to Claude as callable tools. The demo is scripted. The MCP server is real code Claude can actually invoke.
I was the product direction. Claude Code was the build. The architecture, the scenarios, the data model, the policy logic, and the domain decisions are mine. The code was AI-assisted and I'm transparent about both, because that's how I'd work on any team.
Read the full story (pitch deck) →See It Working
Built with React + Claude Code · Two scenarios, fully scripted
The fastest way to understand the concept is to see it run. Two scripted scenarios show what the experience would feel like with full context available to the AI.
Traveler: Sarah Chen, Acme Corp · SkyTeam Platinum Elite · Marriott Bonvoy Platinum
Scenario 1
Calendar Alert → Auto-Rebook
Sarah's London meeting extends by one day. The system detects the calendar change, checks her loyalty status, corporate policy, and available flights, and surfaces a recommendation — without her asking.
30 seconds vs 25+ minutes manualScenario 2
Chat Request → Complex Itinerary
Sarah requests a NYC stopover on the way home from London. The system books the London extension, a transatlantic upgrade using her miles, a NYC hotel, and a return flight — applying her status benefits at every step.
4 changes confirmed in 90 secondsProduct Design
Design Wireframe
Travel policy today is written in documents and enforced manually. This wireframe shows how a Corporate Policy Manager could flip that: instead of writing rules, travel managers describe the business outcome they want, and the system derives the enforceable rules from that intent. A manager types "keep our United partnership healthy until we hit our Q4 volume target" and the system generates route preferences, fare delta thresholds, and volume alerts automatically.
The wireframe annotates nine capabilities: natural language policy input, objective-vs-rule mode toggling, AI-generated derived rules, smart suggestions when rigid rules are detected, starter templates by industry, real-time compliance analytics, and automatic conflict detection between policies. The check_policy_compliance tool in the MCP server is the runtime enforcement layer for policies configured here.
Opens in a new tab · Design wireframe, not a built feature
Working Code
TypeScript / Node.js / Model Context Protocol · GitHub →
Beyond the demo UI, I built a working MCP (Model Context Protocol) server that gives Claude structured access to three enterprise travel capabilities as callable tools: supplier search, traveler preference scoring, and corporate policy compliance.
The Tools
Three structured capabilities
search_travel_options — query flights and hotels by route and city.
get_preference_score — score any option 0–100 against the traveler's profile (carrier, seat type, loyalty, change fees).
check_policy_compliance — validate a proposed booking and return an explicit pass, exception, or violation verdict with per-rule detail.
The Key Design Decision
Policy in a dedicated system, not a prompt
The compliance tool is deterministic and auditable. In this demo it runs as a TypeScript rule engine. In production it would be replaced by an ML model trained on real booking and approval history — capturing the implicit policy that lives in years of decisions, not just the written rulebook. Claude receives a structured verdict either way.
The interesting case: Delta's business cabin normally violates Acme Corp policy (economy and premium economy only approved). But the traveler used loyalty miles for the upgrade — not a fare upgrade. Same cabin, different compliance outcome. The tool handles that distinction explicitly.
Live MCP output in Claude — preference scoring, policy compliance, and actionable recommendations
Built with Claude Code. My role was product direction: the data model, the scenarios, the policy logic, and the vision for how a production system would work. Claude Code wrote the code. Both contributions matter and I'm transparent about both.
How I Approach Product
Four things I do the same way in any industry
Spot the problem before the market does. At Navitaire we shipped ancillary sales infrastructure before seat fees and bag fees were standard practice. Not luck. A product call about what to build, when, and for whom, made when the outcome wasn't obvious. The same instinct drove Veyant: AI agents were getting smart faster than anyone was solving the context problem underneath them.
Architecture before features. Hard problems don't get solved by shipping screens. I start with the data model and the system boundaries, because those decisions compound. Veyant's three-cube architecture exists because "where does the traveler's context actually live" is the question that determines every downstream feature. Works the same way in fintech, healthtech, or any domain where the wrong primitive locks you in for years.
Research, then architecture, then working artifacts. I run new problems the same way whether it's a corporate policy rewrite or an infrastructure concept: understand what's actually broken, design what it should look like, then build enough to pressure-test the thinking. Ambiguous problems don't respond to process. They respond to judgment applied in that order.
Transparent about the work. Domain judgment is mine. AI is a tool that lets one person move faster than a team used to. I don't conflate the two, because the teams I'd want to join don't either.
What's Next
Five months on my own taught me what I do best and what I want next. I want to be part of a team again. One that's highly collaborative, takes real risks, and is building something audacious enough to matter beyond its own category.
The solo path was the right call for a specific question. It's not the right call for the long work. The ideas I'm proudest of in my career came from friction with people who saw the problem differently: engineers who pushed back on my architecture, salespeople who knew the customer I was guessing at, designers who made the thing actually land. Five months proved I can move fast alone. It also proved I don't want to.
I bring 20 years of domain expertise, senior product instincts, and a proven pattern of working at the speed AI now allows. Travel is where those patterns were forged, not the only place they apply.
If that sounds like your team, get in touch.