Every tube app in the world will tell you IF a station has step-free access. None of them tell you WHERE to stand on the platform for the fastest exit. That is a completely different problem. And it is the problem nobody was solving.
So I built First Out. 383 stations across 19 lines: the full Tube network, Elizabeth line, DLR, and all six London Overground lines. It tells competitive commuters where to stand for the fastest exit, which side the doors open, and when the first and last trains run. And for parents navigating with a pushchair and a toddler, there is a dedicated Parent Mode that no other tube app has. Same engine, two different audiences. Two different brands.
That dual-brand decision is the most strategic thing about this whole project. And it came from advertising, not engineering.
The insight that no developer would find
Here is what TfL publishes: CSV files and PDFs buried on data.tfl.gov.uk. Step-free topology data. Platform gap measurements in millimetres. Lift specifications. Interchange distances. It is all there, technically public, and practically invisible. No normal person is reading a CSV file to decide whether they can get a buggy through Bank station.
A developer would see that data and think: accessibility feature, checkbox, done. A strategist looks at the same data and sees two entirely different user needs hiding inside the same dataset.
A wheelchair user needs to know: can I get from street to platform without stairs? That is a binary question. Yes or no. 103 of 383 stations say yes.
A parent with a buggy needs to know: how wide is the platform gap? Will I need to fold the pushchair? Is there a lift or just an escalator? Which carriage should I board so the exit is right there when the doors open? Is there baby changing? What is the least stressful route across the whole network?
Those are entirely different questions. And nobody was answering the second set.
Parsing the data nobody reads
TfL is generous with its data, in the way that governments are generous with information: it exists, it is technically available, and it requires significant effort to make useful. We parsed their step-free topology CSVs, their ELRAD XML accessibility files, and cross-referenced everything against the 383 stations in the First Out database.
The result: 103 stations with some level of step-free access. 60 with full step-free access from street to platform. 21 with partial access. 22 with step-free interchange between lines but not from street level. 84 stations with lifts. 130 with toilets. Platform gap measurements. The lot.
But data without context is just a spreadsheet. The real product decision was how to present this information to two audiences who want the same underlying facts for completely different reasons.
Two brands, one engine
First Out is for the commuter who treats the tube like a competitive sport. Dark UI. Sharp. The tagline is "the fastest way off the tube." The energy is IYKYK. You either care about this or you do not, and the people who care about it really care.
Buggy Smart is the same data, the same engine, but wrapped in reassurance instead of speed. The question shifts from "how do I save 30 seconds?" to "can I actually do this journey without a nightmare?" Different tone, different hierarchy of information, different entry point. Same product underneath.
This is a branding decision, not a technical one. A developer builds one app with a toggle. A strategist builds two brands with different positioning, because the audiences have fundamentally different emotional states. The commuter feels competitive. The parent feels anxious. You cannot serve both feelings with the same tone of voice.
What this says about who gets to build
I built this entire thing with Claude Code. No development background. No engineering degree. I am a strategy director who spent fifteen years in advertising agencies writing briefs and presenting decks.
But here is the thing that matters: the hardest part of this project was not the code. It was the decisions. Which data to parse. Which audiences to serve. How to position two brands against the same dataset. What information to surface first, second, and not at all. Whether to lead with speed or safety. How to name it. How to frame it.
Those are strategy decisions. They are the decisions that determine whether a product feels right or feels generic. And they are the decisions that AI tools cannot make for you.
AI can parse a CSV. AI can build a PWA. AI can match 383 stations across multiple datasets. What AI cannot do is look at step-free accessibility data and see two underserved audiences with conflicting emotional needs. That requires taste. That requires understanding people. That requires the instinct that comes from fifteen years of figuring out what audiences actually want, not what they say they want.
The uncomfortable slide
If I were presenting this at an agency, here is the slide that would make the room go quiet. First Out: 383 stations across 19 lines, 95+ features including first and last train times, door-side indicators, community verification, real-time TfL integration, offline-capable PWA, dedicated Parent Mode with a separate brand identity. Built by one person. No development team. No sprint planning. No Jira board.
The traditional way to build this would involve a product manager, a UX designer, two or three developers, a data engineer, and a project manager. Six months minimum. Six figures of budget, easy.
This is not a criticism of teams. Teams build things that last and scale. But the gap between what one person with AI tools and strategic thinking can build versus what organisations assume requires a team. That gap is the story of the next decade. And most organisations have not noticed yet.
Taste plus strategy plus AI tools equals real products. Not prototypes. Not mockups. Not decks. Products with URLs, with users, with data that updates. The kind of thing that makes someone say: "Wait, YOU built this?"
Yes. I did. And the strategy background was not the obstacle. It was the advantage.
