Announcing Faster Drafts: How We Cut Planning Time Further

A first trip draft used to feel like a small act of patience: you'd answer Marlow's questions, then wait while the pieces came together. That wait has gotten shorter, and it's worth explaining how, because "we made it faster" is a hollow claim on its own. The interesting part isn't the speedup, it's what we refused to cut to get there.

Every planning system has a shape: a series of steps that turn a traveler's answers into a real, bookable draft. Destination research, flight and hotel availability checks, day-by-day sequencing, budget balancing. The naive way to build that pipeline is to run each step after the last one finishes, like a single line at a checkout counter. It works, but it's slow in a specific and fixable way: most of those steps don't actually depend on each other finishing first.

The Idea: Stop Waiting in Line for Steps That Don't Need to Wait

The biggest lever behind a quicker first pass is parallelization, running independent steps at the same time instead of one after another. Checking hotel availability in a destination doesn't require knowing the final flight time down to the minute. Pulling general destination knowledge, like which neighborhoods suit a walkable trip or which season is shoulder season, doesn't depend on the specific dates being finalized first. When steps like these can happen at once instead of in sequence, the total time to a first draft drops without anything about the underlying checks getting shallower.

A person planning a trip manually has to work through things somewhat in order, since a person can only hold one tab open at a time. Software doesn't have that constraint, so a planning system that mimics a human's sequential habits by default is leaving speed on the table for no real benefit.

The second lever is caching common destination data. A large share of what goes into a first draft isn't unique to any one traveler's request. Whether a neighborhood in Lisbon is walkable, what shoulder season looks like in Portugal, which general activity categories suit a relaxed pace versus a packed one, this kind of information gets looked up constantly across many similar trips. Recomputing it from scratch every time is wasted effort. Storing the stable parts of that knowledge and reusing them, while still checking the parts that actually change trip to trip, like live pricing and real-time availability, cuts a meaningful chunk of repeated work without touching the parts of the draft that need to stay current.

The distinction matters: caching applies to things that don't change often, not to things that do. A hotel's general location and reputation are relatively stable. Its price and open rooms for a specific week are not. A system that caches the second kind of information risks handing a traveler stale numbers, so these improvements are deliberately scoped to the parts of the picture that are safe to reuse.

What Actually Changed vs. What Stayed the Same

The table below separates what changed technically, the general idea behind each change, and why none of it comes at the cost of draft quality.

The Part That Didn't Change: Human Review

Every draft, no matter how quickly it comes together, still goes through the same human review before anything gets booked. Speeding up the drafting stage was never going to be worth much if it meant loosening the process that catches pricing shifts, hotel quirks, and the gap between what a traveler said and what they actually meant.

That holds because the speed improvements and the review step live in different parts of the system. Parallelizing steps and reusing common destination data both happen before a draft reaches a person. The advisor's job, checking real availability, confirming pricing hasn't moved, catching the kind of mismatch a pattern-matching system can miss, is unaffected by how quickly the draft in front of them was assembled. A faster first pass just means the advisor gets a solid starting point sooner, not a thinner one.

It would have been easy to hit an impressive speed number by trimming which checks run before a draft is shown, or by skipping review for "simple" trips. We didn't, because the entire value of Tripdash rests on "plan free, book human" meaning something. A fast draft that skipped verification wouldn't save anyone time; it would just move the delay to later, when a traveler discovers a problem an advisor would have caught.

Where the Improvements Apply, and Where They Don't

The gains here are specific, not a blanket claim that everything is now faster everywhere. It's worth being clear about the boundaries:

• The first draft assembly is where the time savings show up, since it's built from a mix of independent lookups that benefit from running in parallel
• The advisor review stage isn't mechanically sped up, because it involves judgment calls that take the time they take, regardless of how the draft was assembled
• Complex, multi-destination trips still take longer to draft than a simple long-weekend trip, since there's genuinely more to check and sequence
• Live pricing and availability are never cached, since caching only applies to information that's stable enough to reuse safely
• Redundant lookups were consolidated, not removed, so the same checks still happen, just without duplicating effort
• The scope of what gets cached is deliberately narrow, limited to destination knowledge that doesn't shift trip to trip

Why This Approach, Not a Shortcut

There's always a faster way to make something look faster: cut a verification step, lower the bar for what counts as "done," or hide latency by returning a rougher answer earlier. Those approaches produce a number that looks good in a release note and a product that's worse to actually use. We wanted the opposite tradeoff.

The guiding principle was that speed should come from removing waste, not from removing work. Running independent steps at the same time doesn't remove any of the checks a draft depends on, it just removes the artificial waiting between them. Reusing stable destination knowledge doesn't remove the lookup, it removes the pointless part where the same stable fact gets recomputed again. Neither of these touches the parts of the system where staleness or shortcuts would actually hurt a traveler: live inventory checks, pricing, and the human review that catches what automation can't.

What This Means the Next Time You Use Tripdash

In practical terms, the wait between answering Marlow's questions and seeing a first draft should feel shorter, without any change to what that draft is built from or what happens to it afterward. The same live flight and hotel checks run. The same destination knowledge gets applied. The same human advisor reviews the plan before you'd ever be asked to book anything.

This isn't a one-time project with a finish line either. It's ongoing work that continues as more trips flow through the system and more patterns emerge about which steps are genuinely independent and which destination data is stable enough to reuse safely. What won't change is the boundary around advisor review. That's not a bottleneck we're trying to engineer around; it's the part of the process that makes the rest of it trustworthy, and it stays exactly as it is regardless of how fast the draft in front of the advisor comes together.