Layover
Why I built it
A long layover at Dubai is not a boredom problem, it is an uncertainty problem. You do not know whether you are allowed to leave, and you do not know how much of your layover is actually yours. Most travellers assume they have the whole window. They lose thirty to eighty minutes getting out and need ninety to get back, so on a six-hour layover more than half is gone before anything happens.
The decision that mattered
No language model anywhere in the plan output. Everything is deterministic: the visa check, the time arithmetic, the filtering, the leave-by times. A hallucinated turn-round time is a missed flight, and no amount of usually-right makes that acceptable. The same reasoning that keeps a model out of a fee calculation keeps it out of this.
The blocker is not boredom, it is not knowing
Two questions stand between a traveller and a layover worth having, and an airport is the worst possible place to answer either.
The first question is whether you are permitted to leave at all, which depends on your passport and is genuinely hard to establish from a terminal on poor wifi with a departure board counting down. The second is how much time you actually have, which is never your layover duration.
Getting out of Dubai International takes between 30 and 80 minutes depending on the terminal and whether you are collecting bags. Getting back safely needs 90 minutes, fixed. Below four hours in total there is no exit worth attempting, and the tool says so rather than trying.
Each half of the answer exists. Nothing puts the two together.
Everything a transiting traveller can reach either tells them what is in Dubai or tells them whether they may enter it. Nothing does the arithmetic that decides whether either matters.
Layover guides. Written once, personalised to nobody, and usually out of date on opening hours. They tell you what is in Dubai, not what fits your Tuesday.
The airport’s own app. Excellent for the terminal you are standing in, and silent on whether you may leave it. Its job ends at the door this tool is asking about.
Visa checkers. Accurate, and framed around entering a country rather than transiting one. They answer the first question and stop, which is the point at which the arithmetic starts.
Maps and route apps. They will price the journey to a place in minutes, once you already know where you are going and that you are allowed to go.
Layover. Runs the eligibility check and the arithmetic together, then filters what is left down to what is genuinely reachable and open, with a leave-by time on every option.
The brief said 40 nationalities. It ships with 195
Scoping the visa table to the most common passports would have been faster, and it would have failed the exact people who most need an answer.
The original plan covered the top 40 nationalities by transit volume. That is a defensible engineering decision and a bad product one, because a traveller whose passport is not on the list gets nothing from the tool at the precise moment they are least able to find out elsewhere.
It ships covering every nationality across three tiers, with anything not explicitly free-on-arrival or transit-visa defaulting to "advance visa required, you cannot exit". The default is the safe answer, so an omission in the data can only ever make the tool too cautious, never too permissive.
The same instinct runs through the edge cases. Refugee documents, stateless travel documents and non-biometric passports override the nationality answer entirely. Countries whose policy is genuinely in flux carry a verify-before-you-fly warning instead of a confident wrong answer. Where a traveller might qualify through a residence permit the tool cannot see, it surfaces the possibility rather than deciding.
Four questions, answered in order.
Each one can end the plan. The first answer that says no is the answer, which is why the visa check runs before anything is suggested.
Can you leave?
Nationality against a three-tier table covering 195 entries, plus a document-type check. Tier 3 stops here with guidance for staying inside, because there is no honest plan to offer.
General guidance, drawn to show the shape of the decision. The tool itself does not use these ranges: it works from DXB’s own per-terminal exit times and a fixed 90-minute return buffer.
The bug that taught me the most
An evening query with a window of more than twenty hours was returning six free spots and no paid attractions at all. The symptom looked like a pricing bug. It was an opening-hours bug: every daytime attraction was being excluded because it was closed right now, on a plan that stretched comfortably into the following afternoon.
The fix was to stop asking "is this open?" and start asking "is there any opening window inside the traveller’s usable time that fits the visit and the journey back?". Spots you would wait for now say so, with the time they open. It is the difference between a tool that knows the clock and one that knows the plan.
A shared link has to work with no signal
The first version of the share link encoded the inputs and re-ran everything on open, which meant a fresh round of live calls and a sign-in gate for whoever received it. On airport wifi that is a dead link, and the whole point of saving a plan is the moment you lose connection in a taxi.
It was rebuilt as a server-side snapshot: the finished plan is stored, and the link renders it whole with no live calls and no gate. There is a QR code next to it labelled for exactly this, because the device you planned on is often not the device you leave with.
Every entry, across three tiers. Anything not explicitly tier 1 or 2 defaults to cannot-exit.
Matched one to one against the spot list, including seasonal and Ramadan behaviour.
Hardcoded and not user-adjustable. The one number nobody gets to optimise away.
Live, with its unfinished business written down.
Public and working, with live traffic, real road geometry, weather and heat warnings, multi-stop itineraries and offline plan snapshots.
In production, on a real domain
Every nationality, every spot with its own opening hours, and a leave-by time on each option. No language model anywhere in the plan output.
The success criterion has not been met
The test set at the start was that several people would use it and report the time arithmetic felt trustworthy. That has not happened. It sits in the project notes as outstanding, and it stays there until it is true.
Estimates are presented more precisely than they are known
The exit times are curated figures shown as single numbers. A range displayed as one number is a small dishonesty, even when the number is the best available.
What I would do differently
- Model opening hours from the start. They were not in the original scope and they turned out to be the difference between a plan that fits on paper and one that works.
- Design the offline case first. The product exists for people with bad connections, and the first share implementation assumed a good one.
- Never style an estimate like live data. A static fallback once carried a pulsing indicator that read as a live feed. It was corrected, but it should not have shipped, and the general problem of showing provenance without burying the traveller in it is still open.
More projects.
Let’s build something that scales.
If you are trying to make content compound rather than accumulate, that is the problem I like most. Email is quickest, and my calendar is open.