We're going to try doing this regularly: a short, honest note about what broke and what we changed. Not a feature announcement — the actual bugs, found on real trips.
Two from this week, both good examples of how travel software fails.
The lunch at midnight
A user planned Copenhagen to Stockholm. On the travel day, our plan gave them a lunch reservation at 22:30.
Not a wrong restaurant. A real, excellent restaurant — scheduled at half past ten at night, for lunch.
What happened: the day was overfull, and we have a rule that meals are never dropped from a plan. Three meals a day is a hard promise. So when the schedule got crowded, everything else shifted, and the lunch got pushed later, and later, and nothing stopped it, because the only limit was the end of the day.
The rule was right. The absence of a bound was wrong. A meal isn't sacred in the abstract — it's sacred because you'll be hungry at that time. A lunch at 22:30 isn't a lunch; it's a bug wearing a lunch's clothing.
So now meals have windows. If a lunch gets pushed past mid-afternoon, we drop it rather than pretend. You don't need us to find you lunch at midnight, and a plan that shows you one has told you something false about the whole day.
The two Charlestons
Someone planned a trip from Charleston, West Virginia to Charleston, South Carolina. Deliberately — two different cities that share a name, about 500 miles apart.
We merged them into one.
Our planner groups consecutive days in the same city so it can plan them together. It compared city names, saw "Charleston" and "Charleston," and concluded this was one nine-day stop. The plan then drifted to the more famous Charleston for most of the week, and one day ended up with a South Carolina lunch sitting between two West Virginia meals.
The maddening part: we'd fixed the opposite bug two days earlier. A hotel saved as "København" wasn't matching a destination saved as "Copenhagen" — same city, two languages — which slid a travel day a full day late. The fix for that one made name comparison more forgiving. This one needed it stricter.
The rule we landed on: names match through a translation table (København is Copenhagen), but if both places name a region, the regions have to match too (West Virginia is not South Carolina). Same city in two languages, yes. Two cities with one name, no.
Why we're writing this down
Because every travel app has these, and most of them quietly patch and move on.
We'd rather tell you. Partly because the bugs are genuinely interesting — they're all versions of "a place name isn't an identity," which turns out to be the hardest problem in this entire product. And partly because if you're going to trust a piece of software with a trip you've saved for, you should know how its makers behave when it's wrong.
We find these by QA-ing real trips, every week. If yours has something odd on it, tell us — that's how both of these were caught.