case study · project 02

Layovr

A layover explorer that turns dead airport time into the best part of your trip — personalised to your passport, your time, and what you actually want to do.

↗ visit layovr.org ← all projects
TypeSolo indie project
StatusLive · active
StackHTML · Claude API
ArchitectureSingle-file · Netlify
Inspired byPrague, Budapest, Istanbul

the problem

Most layovers are completely wasted.

A 5-hour layover in Prague. A 6-hour stop in Istanbul. Most travellers sit in the terminal, scroll their phone, eat bad airport food, and wait. Not because they want to — because they have no idea what's possible, how long things take, or whether they even need a visa to leave the airport.

The information exists. It's scattered across travel blogs, Reddit threads, embassy websites, and forum posts from 2017. Nobody had assembled it into something that actually answered the one question travellers need: what can I realistically do in the time I have?

"Prague was a 5-hour layover. Budapest was a connection. Some of my best travel memories came from time I almost wasted sitting in a departure lounge."

the audience

The traveller with time between flights.

Layovr is for travellers with a window between 3 and 12 hours who want to make the most of it. They're not necessarily travel experts — they might have a connecting flight in a city they've never visited and no idea whether to venture out.

The tool needed to be trustworthy above all else. Getting the visa situation wrong, or underestimating transit time, could mean missing a flight. That created an unusual design constraint: the product had to be honest about what wouldn't fit, not just enthusiastic about what might.

at a glance
3
Inputs needed
airport, duration, passport
Visa check
built into every result
0
Sign-ups needed
ever
the product

Your layover, personalised.

Three inputs: your airport, how long you have, and your passport nationality. Layovr generates a practical itinerary — what you can realistically see, how long transit takes each way, visa requirements for your nationality, and what to prioritise if time is tight.

Layovr screenshot

Every recommendation is framed around time: how long to get there, how long to spend, how long to get back. A list of tourist attractions is useless without this context. The format was designed to answer "can I actually do this?" before "is this worth doing?"

architecture

Same lean stack, higher stakes.

Like Farebones, Layovr is a single HTML file with no framework, no build step, and no backend. The Claude API handles all contextual intelligence: visa rules by passport nationality, realistic transit times, local highlights worth the trip, and honest time calculations.

The higher stakes compared to Farebones — missing a flight is expensive — meant the prompt engineering had to be significantly more careful. The AI needed to err on the side of caution with time estimates and be explicit about visa uncertainty.

HTML/CSS/JS Claude API (Anthropic) Netlify CDN Single-file architecture Passport-aware prompting Zero dependencies
key decisions

Built around real constraints.

01
Passport as a first-class input

Visa requirements are the single biggest practical constraint on what a traveller can do during a layover. Building nationality into the core input — not a footnote — meant the output was actually trustworthy and personalised, not just a generic list of things to do near the airport.

02
Time-first design

Every recommendation surfaces transit time, duration, and return time before anything else. A stunning cathedral that takes 90 minutes to reach isn't a recommendation for a 3-hour layover. The tool had to understand the difference between "interesting" and "feasible."

03
Honest about what won't fit

Most travel tools are optimistic to the point of irresponsibility. Layovr was designed to tell you when something isn't realistic — and give you a tighter, more achievable plan instead. That honesty is the product's most important feature.

04
Built from personal experience

Prague, Budapest, and Istanbul were all layovers turned into real experiences. The product understanding comes from having actually felt the anxiety of "is this worth it or will I miss my flight?" — not from a user persona document.

challenges

The parts that were genuinely hard.

Visa accuracy without a database. Visa requirements change frequently and vary enormously by passport. Rather than maintain a static database that would go stale, the prompt instructs the AI to be conservative and flag uncertainty — but this required careful calibration to avoid being so cautious the tool became useless.

Transit time realism. Getting from an airport to a city centre and back is never as simple as Google Maps suggests — there's check-in time, immigration, potential delays. The prompts needed to encode realistic buffers that felt helpful rather than paranoid.

Scope discipline, again. The temptation was to add flight status integration, live transit data, hotel recommendations. Each would have made the tool "more useful" in theory while making it less immediately useful in practice. Layovr does one thing well.

what I learned

What it proved.

The best products solve problems you've personally felt. Layovr exists because I've sat in airports knowing I could have been somewhere better. That personal frustration made the product decisions obvious in a way that user research rarely does.

Trust is a feature. An AI travel tool that gets you stranded is worse than no tool. Building explicit uncertainty and conservative time estimates into the product made it more trustworthy, and therefore more useful, than a tool that just told people what they wanted to hear.

Constraints are creative. The single-file, zero-dependency architecture forced the product to be ruthlessly focused. Every feature that required a backend was cut. What remained was sharper for it.

"Indie tools can be serious products. The difference between a weekend project and a real product is the quality of the thinking behind it — not the size of the team."

previous case study —
Farebones
read case study →