Cutting a Green Travel App Down to One Thing That Worked.
A UK startup wanted an app that moved football fans to matches without cars. We shipped a carpooling MVP instead of the full multi-modal product — because one testable assumption beats four blocked integrations.
A UK startup came to FrixB with a zero-emission travel product: get football fans to matches by train, bus, bike, on foot or by carpool, and show them the carbon they saved. We ran the discovery, designed the product, and built both front end and back end. The most valuable thing we did was argue the scope down — shipping carpooling alone, because it was the one mode that could test the idea without waiting on anyone else’s data.
1 of 5 modes
shipped first — the only one with no external dependency
Two-sided
driver and passenger flows designed as separate products
Design + build
UX through to front end and back end, one team
A green travel app that couldn’t launch until four other companies cooperated.
The original concept covered five travel modes. Four of them — train, bus, bike hire, walking routes — needed live timetable and availability data from external providers, each with its own integration, contract and reliability risk. Meanwhile the central premise was unproven: nobody knew whether fans would actually change how they travel to a match. The product was structured so that the cheapest question to answer was gated behind the most expensive work.
- Cut scope to the one mode that owned its own data: Carpooling needs no third-party feed — the supply is the users. It was the only mode that could ship on our own timeline and still test whether fans would share a journey at all.
- Designed driver and passenger as two products, not two permissions: Offering a ride and finding one are different jobs with different anxieties. Each role got its own navigation, its own empty states and its own live-ride view rather than a shared screen with toggles.
- Built a pickup handshake for strangers: Meeting an unknown driver in a crowded match-day car park is the moment the product either earns trust or loses it. A scan-and-show QR exchange confirms both parties before anyone gets in a car.
- Made the live ride a sequence of states, not a status label: Before arrival, at pickup, trip started, heading to destination, arrived, ended — each is its own screen. Ambiguity about where the other person is, is what makes ride-sharing stressful.
- Let drivers charge a small fare, and let them not: A fare-per-passenger field encourages supply; a Free Ride option removes the friction that kills a cold-start marketplace. Both exist because neither alone solves the two-sided start.
Discovery ran on client interviews and proto-personas rather than fan research — a constraint we were explicit about, and one that shaped the whole approach. Since the core assumption about fan behaviour was untested, we designed the smallest product that could test it honestly rather than a full build resting on assumptions nobody had checked. FrixB then carried it through front end and back end, so the reasoning behind each decision survived into shipped code.
Ship one travel mode, not five.
Building all five modes would have made a more impressive launch and matched the original brief. We argued against it: four modes were blocked behind third-party timetable APIs, and every week spent integrating them was a week not spent finding out whether fans would change their travel habits at all.
Trade-off: the MVP launches as a carpooling app rather than the green-travel platform the client pitched, and the carbon-saving story waits for phase two. In exchange, the central assumption gets tested months earlier and at a fraction of the cost.
A match-day carpooling app, built to be extended.
Fixture-led browsing, ride offering and booking, guest and registered paths, QR-verified pickup, staged live-ride tracking, in-app chat, ratings, flexible fares and full cancellation handling on both sides.
125 screens across two user types, architected so the remaining travel modes and the carbon-saving layer drop in without a rebuild.
A complete two-sided product, built and ready to launch.
Delivered end to end: 125 screens across driver and passenger, with front end and back end built by FrixB.
De-risked scope: the one mode with no external dependency shipped first, with the rest architected in.
Launch pending: the client has not yet released the app, so no live usage data exists to report.
Learnings & Next Steps
The most valuable thing we did on this project was subtract. A brief that lists five features is often really one hypothesis wearing five costumes, and finding the cheapest honest test of that hypothesis is the actual design work. What we would change: we accepted proto-personas built from client feedback where the product’s central risk was behavioural — the one thing worth spending real research budget on. Next time that argument comes earlier.
“Fantastic work carried out on time, surpassing expectations”
Got a big brief that needs cutting down to something shippable?