The people behind Fortrip.

Derrick co-founded Fortrip out of a specific frustration. Years of travel had shown him the same problem from multiple angles: planning tools that presented options without helping you choose, itineraries that held together on a screen but fell apart in practice, and a process that got harder the more carefully you tried to do it.

His background is in product and systems thinking — figuring out where something breaks, then designing a fix that holds. He approaches a messy problem by reducing it: identifying which constraints are real, which parts depend on which other parts, and what a solution actually needs to do. That thinking shaped Fortrip from the start — not as a better interface on top of the same planning logic, but as a rethinking of what travel planning should be doing in the first place.

He believes most travel tools were built to surface information faster. Fortrip was built to help people make better decisions with it.

Shuhao co-founded Fortrip because he'd never been able to let a trip be mediocre. He grew up planning trips across months rather than weekends, became the friend everyone asked before booking, the family member who designed the route. None of that scales beyond a small circle. The AI tools that should have scaled it weren't doing the thinking part — they retrieved, they summarized, they didn't push back when push-back was the help. That gap is the kind a model with the right architecture could close.

He came at it with broad engineering — product, applied AI, full-stack, distributed systems. The point of breadth isn't generalism. Failure modes in a system like Fortrip's don't respect layers: a bad answer can come from a weak prompt, a wrong index, a slow model, or a UI hiding the right output. Someone has to be responsible for catching it regardless of where it lives.

He's a systems thinker by reflex. Where most people see a trip plan, he sees constraints, dependencies, and the small failures that only surface mid-trip — the rushed Day 3, the well-reviewed hotel forty minutes from everything that mattered, the route that looked clever on a map and lost half a day. These aren't mysteries. They're patterns, and patterns are tractable.

He's building the planner he wishes he'd had access to himself — the one that catches what an experienced traveler would catch, at the scale a model can run.

Bruce came to Fortrip through a frustration most travelers quietly share. Years of traveling across North America had given him a close view of how often a trip that looked good on paper failed in practice — not from bad luck, but from the way planning tools are built. They surfaced options without explaining them. They gave recommendations without accounting for where things actually were or how long it took to move between them. The problem, he concluded, wasn't too little information. It was too little thinking built into the tools.

His background is full-stack — frontend, the API layer, and the engineering work in between. The part he cares about most is how a system feels to the person using it, and what separates something people trust from something they abandon halfway through. He notices where a flow loses someone, what a recommendation needs to actually be useful, and what happens when a plan meets reality on day two. At Fortrip, that instinct shapes how the product presents what it knows: not just whether the reasoning is right, but whether someone can act on it.

He joined because Fortrip was built on a different premise — that travel planning needs something that reasons about a trip, not just retrieves information about it. His job is to make sure that reasoning reaches the person on the other side in a form they can actually use.