A Pottery Class in Tribeca
I needed to get from Park Slope to a pottery class in Tribeca. Google Maps gave me two options. Subway, forty-five minutes. Bike the whole way, fifty-two minutes. Neither felt right. I picked a third that Google wouldn't suggest: bike five minutes to Atlantic Terminal, take the subway to Chambers, walk two blocks. Thirty-one minutes.
Every real New Yorker does that kind of swap constantly. The apps pretend it doesn't happen.
That gap is what became WalkRide. A 24-hour build. Shipped live. Still running.
Why Mapping Apps Break in Cities
Most people in cities don't commute in one mode. A trip rarely follows one line. You walk to the subway, get off two stops early, grab a bike for a stretch, then walk the rest. The combination changes based on time of day, how much energy you have, and whether you're dressed for cycling.
Mapping apps optimize for the easiest answer to compute, not the fastest real route. "Take the subway" is one query. "Combine walking, biking, and transit, ranked by time, with live dock availability" is five APIs and a composition problem. Nobody wanted to ship it.
So I did. Over a weekend.
The 24 Hours
The build ran Friday night through Saturday night. Scope was obvious from the start: NYC-only, multimodal routing, two sliders for walking and biking tolerance. Input a start and an end, get back a ranked list of mixed-mode options.
Most of the time went to API orchestration. Four sources had to talk to each other. Mapbox for walking and biking directions. Google Maps (proxied through a Supabase edge function) for subway, bus, and ferry routes. Citi Bike's GBFS feed for live station availability. PostHog for tracking which routes people picked.
The trick wasn't any single API. It was running them in parallel and stitching the results back fast enough to feel responsive. When someone sets walking tolerance to 20 minutes and biking to 15, the system doesn't make six sequential requests. Calls fire simultaneously, come back asynchronously, get composed into routes, get ranked by total time.
A two-second difference between sequential and parallel requests sounds small. Multiply it by every query and it's the difference between a tool that feels alive and a tool that feels broken.
The frontend was the easy part. React 18 with TypeScript, Vite, Tailwind, TanStack Query for the data cascade. Nothing exotic. ChatPRD mapped the user flow before any code got written. Lovable scaffolded the first interface. The load-bearing work was custom. Everything else came off the shelf.
Three Decisions That Changed How It Felt
Sliders instead of dropdowns. Dropdowns force discrete choices (0, 15, 30 minutes). Sliders let you dial in exactly what you're willing to do. Set walking tolerance to 12 instead of 15, watch the result set update in place. Small mechanical difference. Enormous feel difference.
MTA line colors baked into the route display. Most digital transit apps use generic grey or blue for subway legs. WalkRide pulls the official MTA color for each line. The F train is orange. The L is grey. Your eyes scan for the color before you read the label. Design debt avoided by borrowing from a system that already works.
GPS navigation with live segment tracking. This one mattered most. Mid-ride, knowing which leg you're currently on is the difference between trusting the app and fighting it. Live tracking shows across walking, biking, and transit legs with updated ETAs for each segment. It's the detail that turns a route planner into a navigator.
Each of those took under an hour to build. Each one shifted how the app felt.
What Shipping Fast Taught Me
The usual way to approach a build like this is four to eight weeks. Two weeks architecting, two weeks designing, four weeks coding, one week testing. That timeline costs you two months of moving forward on an idea that might be wrong.
WalkRide hit the idea in 24 hours. Not by cutting code quality. By cutting everything that wasn't essential to answering the core question: does mixing transit modes save people meaningful time?
The answer was yes, especially in outer Brooklyn where the subway network is sparse and last-mile cycling becomes the shortest path. That's the insight the build proved.
Everything else got cut. No auth. No payment. No admin dashboard. No mobile app store. No support workflows. None of it was required to answer the question.
The skill in a 24-hour build isn't coding speed. It's knowing what's load-bearing and what isn't. For route planning, that's real APIs, a live map, and concurrent request handling. For a B2B tool, it'd be user management. For a marketplace, payment processing. Every product has a short list of things it can't skip and a long list of things that feel essential but aren't.
Finding the short list is the work.
Where WalkRide Lives Now
The app is live at walkride.teamvince.com. Set your walking and biking tolerance, plan a trip, see what routes surface. It's designed to feel immediately useful, not like a demo.
If you spot gaps like this in your own workflows or products, places where the tools you already use miss obvious solutions, that's a prototype waiting to ship.
More on the pattern behind this kind of fast build in what I teach through public building.