Intro
Flighty is teaching travelers to avoid connection chaos, one tight layover at a time. Every time you book a flight with a connection, you're making an implicit bet. You're betting that the airline knows what they're doing. That their system has calculated the risks. That if they're willing to sell you a 55-minute connection in Doha, it must be... reasonable. Safe, even. This is the invisible contract we sign with booking systems.
But here's the thing about booking systems, they're not designed to protect you from risk. They're designed to complete transactions. To present options, accept payment and move on to the next customer. Your 55-minute connection? It cleared the technical threshold. The system said yes. That's all it was designed to do.
There's a gap here. A gap between what booking systems optimize for (conversion) and what humans actually need (informed decisions). Between what's technically possible and what's actually advisable.
Most of us never think about this gap until we're sprinting through an unfamiliar airport at midnight, watching our departure gate number get further away with each step. This is about that gap and the app trying to bridge it that's trying to bridge it with their new feature.
The discovery
I'm flying home to Kenya in a few days. London → Doha → Nairobi. I was rescheduling a months-old British Airways booking. Everything seemed fine 🥁🥁🥁 until I added it to Flighty. That's when I saw it.
An amber icon of someone rushing 🏃🏾♂️ My gut immediately told me something was off, but I didn't know what exactly, so I tapped the badge. Turns out there's something called MCT (Minimum Connection Time). I just learned something new aaaand now I'm sweating 😰
Design decisions
Here's what Flighty did with their brilliant design decisions that made this moment both educational and genuinely useful:
Visual hierarchy that demands attention
The amber color → "Tight" label → rushing person icon. Your attention goes straight there. No buried fine print. No wall of text requiring you to dig through flight details. Just unmistakable communication" (immediate is implied).
Compare this to how British Airways presented the same connection when I booked: silence. The booking flow approved it, took my money and never once suggested this might be risky. Although I do like the Avios points I get 🙃 Flighty understood something fundamental about information design: if something matters, it should look like it matters.
Progressive disclosure done right
The initial screen gives you just enough information to know there's a problem. One tap and you get the full explanation. Flighty doesn't overwhelm you upfront, but the information is immediately accessible when you need it.
The expanded view shows a scale of where your connection time sits relative to the airport's MCT. This is information architecture done right. Give people the headline first. Let them choose their own depth.
The handwritten detail
But here's what elevates this from good to brilliant: the handwritten annotations on the scale. It's not just text explaining the concept, it's a diagram that lets you see your risk level at a glance. It's the design equivalent of someone grabbing your shoulder and saying, "Hey, you really need to pay attention to this."
The handwriting makes it feel personal. Like a friend circling something urgent on a map for you, adding their own commentary in the margins. It stands out on an otherwise polished interface and that's precisely why it works.
Understanding MCT
Let's talk about what Minimum Connection Time actually is, because this is where things get interesting aka the hidden language of airports.
MCT is an official standard published by airports, not airlines. (So I guess British Airways has no obligation to show it to customers.) It represents the absolute shortest time you need to make a connection at that specific airport. It's calculated uniquely for every airport based on dozens of variables:
- Physical infrastructure: How far apart are the terminals? Are there trains, buses or do you walk? How long does that journey actually take?
Take London Heathrow, for example. British Airways operates from Terminals 3 and 5. If you're connecting within the same terminal, the MCT is 75 minutes. But if you need to transfer between Terminal 3 and Terminal 5? That jumps to 90 minutes because you need a bus transfer. In January 2024, British Airways actually increased their Heathrow MCT from 60 to 75 minutes specifically to reduce missed connections and create "a more stress-free connecting experience." They saw the data. Too many passengers were missing flights. The economics of rebooking, customer service calls and compensation claims outweighed the conversion benefits of offering tighter connections.
- Operational complexity: International → international vs. domestic → international? Do you need to clear customs or immigration? Do you need to collect and recheck baggage? Different airlines vs. same airline?
This is crucial. At Southampton Airport, the MCT is just 45 minutes, but that assumes you've already checked in, your luggage has been checked through and you're simply exiting arrivals and proceeding back through security. If you're on separate tickets and need to reclaim baggage? British Airways recommends a minimum of 4 hours at Heathrow.
- Seasonal factors: Summer vs. winter (yes, snow affects MCT). Peak travel periods when lines are longer. Time of day (midnight connections vs. rush hour).
The MCT is calculated assuming both flights are on time. It factors in the distance between gates, possible immigration procedures, security checks and other airport-specific arrangements.
Here's where it gets interesting: airlines can actually request specific MCT values from airports. There's a whole system managed by Amadeus (the global distribution system that powers most flight bookings) where airlines submit requests for minimum connecting times. These requests get reviewed, approved and published through a central database.
This means the MCT exists. The data exists. The knowledge exists. It lives in a system that airlines actively participate in maintaining. And yet, British Airways let me book this connection anyway 😈
This is where the gap reveals itself. The MCT data is technically public but practically hidden. It's buried in airport information pages, airline help centers and GDS documentation. You'd have to know what you're looking for, and know that you should be looking for it in the first place, to find it.
So how do you bridge that gap? How do you surface knowledge that's technically public but practically hidden? Flighty has done some great design that turn MCT from an obscure aviation metric into actionable information, since October 2024. This functionality existed then and I didn't notice and now that I'm writing this, I've gone digging into their Version History from the App Store and found out about it.
Pattern recognition
Once I understood MCT, I started seeing it everywhere.
Naturally, I got curious. If my upcoming Doha connection is tight, what about all my previous flights? Have I been unknowingly playing connection roulette for years? The answer is Yes, because I clearly didn't notice this.
I went back through my travel history.
The verdict: I've flown tight connections before and didn't even know it.
Once you understand the framework, you start seeing risk differently. Every connection becomes a calculation: MCT + historical delay data + terminal layout + time of day + whether you're on one ticket or separate tickets.
That last part is crucial. British Airways explicitly warns:"If you choose to book separate tickets for your journey through Heathrow, we recommend a minimum of 4 hours between flights as you will need to reclaim your baggage and may be required to change terminals."
The same physical journey, same airport, same terminals, same distance, has wildly different risk profiles depending on whether you booked it as one ticket or two. On separate tickets, "if you miss your connecting flight, you will be liable for additional costs for an alternative flight or you may need to purchase a new ticket to continue your journey."
MCT gave me a lens. And now I can't unsee it.
The architecture of risk communication
Here's what this whole experience taught me about how systems communicate, or don't communicate, risk. There are really two types of systems at play here:
Systems that optimize for action:
Booking flows. Checkout pages. Conversion funnels. These are designed to move you forward, to get you to say yes, to complete the transaction. Risk information creates friction. Friction kills conversions. So risk gets abstracted away.
British Airways didn't lie to me. The 55-minute connection cleared their technical threshold. That's all their system needed to know. The fact that it's below the published MCT for Doha? That information lives somewhere else, in help documentation, in fine print, in places you'd only look if you already knew to look.
Systems that optimize for understanding:
Tracking apps. Monitoring dashboards. Pre & post-purchase experiences. These are designed to inform, to give you context, to help you feel in control. They have nothing to lose by being honest. In fact, their value increases when they surface information that other systems bury.
Flighty can afford to tell me my connection is risky because they're not selling me the ticket. Their job begins after I've already committed to travel.
I wish Google Travel would also show MCT info 👆🏾 But here's the interesting tension: when do you tell people about risk?
Tell them too early and you introduce anxiety before it's actionable. Tell them too late and they can't do anything about it. There's a timing problem here that's genuinely hard to solve.
This isn't just about flights. This pattern shows up everywhere:
- Credit card companies don't show you total interest when you swipe
- Social media doesn't show you time spent until after you've doom scrolled and gotten the Apple Screen Time notification at the end of the week
- Self-transfer booking sites mention MCT in their FAQs but don't flag tight connections during checkout
Risk information lives downstream from decision-making because upstream risk kills transactions. The question becomes: as designers, where do we intervene? When do we choose understanding over conversion?
The right answer probably isn't to block all tight connections. It's to make the risk visible and let people decide for themselves. Flighty knows this by ranking for flight connections into Risky, Tight, Normal or Relaxed.
Closing Thoughts
What if they took the next step? What if seeing an MCT warning made me feel like British Airways had my back? What if it positioned them as the airline that helps you make smart decisions, not just complete transactions?
There's a business case for this. Every missed connection costs money, not just for the airline, but for the passenger. Hotel rooms. Missed meetings. Anxiety. Lost trust.
But we won't know until someone tries it. In the meantime, my workflow has changed. For every future booking:
- Open British Airways (or whoever), search for flights
- See connection options
- Open Flighty on my phone
- Check each connection's MCT status
- Check historical delay data for those routes
- Consider whether it's one ticket or separate tickets
- Factor in time of day, terminal changes, baggage needs
- Make an informed decision
- Book the flight that balances price, timing and risk 🎉
Flighty has become my pre-purchase research tool, not just my post-purchase tracking app.
The gap between booking systems and tracking systems will probably exist for a long time. Airlines are optimized for one thing and changing that optimization requires changing incentive structures, which is hard and slow. But gaps create opportunities. Imagine if every airline did that. Imagine if every booking flow did that.
Until then, we work around it. We use tools like Flighty to surface what should have been visible all along. We do the research ourselves. We build our own systems of understanding on top of systems designed for transaction.
It's not ideal. But it's better than sprinting through an airport at midnight, wondering why nobody warned you.
