Designing for the moment your phone stops working

The problem, before it was a product

London is one of the most walkable, transit-rich cities in the world, and the moment you actually need your phone most, stepping off a train and figuring out which exit puts you closest to where you are going, is exactly the moment it is least likely to work. You plan your day with full signal, then the plan and the phone both go quiet the second you are underground.

This isn’t a one-off annoyance, it’s a documented infrastructure gap

As of mid-2026, only around 60% of London Underground stations have any 4G or 5G coverage at all, in tunnels, platforms, or ticket halls. Full network-wide coverage is targeted for the end of 2026. For the entire lifespan of this app’s first release, losing signal underground is not an edge case to design around. It is the default condition.

The competitive landscape didn’t already solve this

Corner is a social bookmarking app that depends entirely on a live connection and a friends’ social graph. Eighty Days is a strong multi-city AI trip planner, but it is general-purpose, leans on AI chat, and carries a different privacy value exchange. Neither was offline-reliable, London-specific, or ad and tracking-free.

Design principles, decided early and held to throughout

• Offline-first is the architecture, not a feature. Everything a user needs mid-trip has to be fully usable with zero connection.

• Curated, not generic. Every spot is personally researched, documented, and verified.

• Free, forever, no ads, no tracking. This shaped real technical decisions, not just a marketing line.

• Respect the data you are building on. Every data source had to support the offline-first promise legally as well as technically.

The legal and licensing work nobody sees, but that shaped the architecture

Google Places was dropped twice because its terms do not permit long-term caching, which directly conflicts with an offline-first app. Photos come from a Wikimedia Commons to Wikidata pipeline instead, free and legally clean with photographer attribution stored per spot. Walking distance comes from Geoapify’s routing API because its terms permit caching results. Transit data comes from TfL’s open data platform. The official Underground map graphic was deliberately not used because it is licensed IP, so the Tube and Rail reference screen is built from real structured data in an original interface.

Real problems, found and actually solved

• A recurring transit-info failure was traced to live TfL fetches silently failing for certain leg types, then resolved with a genuine fallback.

• A geocoding bug matched Sherlock Holmes to the wrong real-world location, caught by verifying against the actual address rather than the name.

• A day-removal feature silently failed on taps because of a rendering incompatibility with dashed borders, found only by reproducing it live and reading the warning.

• Custom start and end points initially fell outside the transit pipeline, then were fixed by treating a custom point as a first-class leg in the same system.

Where it stands

At submission, the app includes 110+ individually researched spots across landmarks, markets, parks, museums, food, and nightlife, a full offline-capable multi-day itinerary builder with real walking distances and step counts, genuine TfL transit data, a from-scratch Tube and Rail reference, and curated itinerary templates built from a real walked route through the city. It asks for nothing but optional location access, used only on-device. No account, no ads, no tracking.

What I’d take forward

Every major technical decision, from the photo pipeline to the routing API and the original Tube reference, traces back to one constraint taken seriously instead of designed around. The real lesson was that taking a documented constraint literally, instead of assuming it away like the competition did, is often where the actual product opportunity is.

Role & Skills

Role: Solo Designer and Builder. Skills: Product Strategy, Data Licensing and Sourcing, Offline-First Architecture, Root-Cause Debugging.