Rebuilding a motorbike touring app with one engineer
The Tours plans motorbike tours around where you are, what the weather is doing, and what you ride. iOS and Android, five languages, shipped for the 2026 season.
Role:
Lead Product Designer
Responsibilities:
end-to-end design, strategy, IA, interaction, UI, design system
Year:
2025/26
Client:
The Tours
17% → 63%
Onboarding completion, season over season
148 → 385
First app opens, June 2025 vs June 2026
38%
Of tracked rides aborting on insufficient GPS - the defect the rebuild surfaced
The situation
The Tours is a motorbike touring app with a seasonal business: it peaks in late spring and bottoms out in December. By late 2025 the peaks were still arriving but everything between them had collapsed - every month from October 2025 through April 2026 came in 42% to 81% below the same month a year earlier, with a December floor of 39 monthly actives. Five people were maintaining a product that had grown more features than any of them could support, and a funding round still hadn't closed.
Onboarding was the clearest symptom: six pages of preferences and a four-page motorbike questionnaire before anyone saw the app. Fewer than one in five people finished it.
Mandate & constraints
Redesign the product end to end, with three things fixed: keep the existing user base, keep the core - tracking, tour discovery, rider and bike preferences - and keep the freemium model, because it was the only revenue there was.
One full-stack engineer. Everything I designed, he built. Scope was a budget, not a preference.
Spring. The riding season is the business. A redesign landing in July has missed the year.
Two platforms from one build, with no second engineer to specialize.
Existing riders had to still recognize the app they'd already paid for.
Decision spine
Decision 1
Stop asking riders for things a machine can look up
The old flow asked for six pages of riding preferences and a four-page questionnaire about the motorbike - displacement, weight, power, riding position - before showing anyone the app. Some of it the routing engine genuinely needs. Some of it was age and gender, which it does not. And the last thing standing between a new rider and the product was a subscription paywall.
The alternative nobody had taken was to get the same data without asking a human for it. A rider knows their make and model. They do not enjoy typing in their bike's kerb weight, and they are not a reliable source for it either. So the bike questionnaire became two fields - make and model - and we pull the specifications from the manufacturer. Preferences went from six pages to one screen carrying only what the engine actually consumes: no age, no gender, and no card before the door.
The trade: we now depend on an external specification source, and a rider with a modified or obscure bike gets specifications that aren't quite theirs. We also have no way to know when that happens - the rider never sees the numbers, so a wrong lookup is silent. That's a gap I'd close next.
Onboarding completion went from 17% to 63%, season over season - where complete means creating and confirming an account, setting riding style and level, adding at least one bike, and reaching the home screen. The bar didn't move. The work behind it did.
Fork
Shorten the form, or stop asking for what can be fetched
Constraint
The personalization engine genuinely needs bike specs
Call
Make and model only; fetch specifications from the manufacturer
Trade
An external data dependency; wrong numbers for modified bikes
Result
17% → 63% completion
Twelve screens before a rider saw a road, ending in a paywall. -> Now three, and the specifications arrive from the manufacturer.
Decision 2
Sending someone out to film roads instead of designing a better static screen
The old first screen was dark green with a logo on it. The cheap fix was a brighter, friendlier static welcome screen, and it would have cost a day.
I chose full-bleed video of real riders, and the reason is specific to this product. Nobody buys a touring app for the app. They buy it for the road they haven't ridden yet, and no static composition sells that in the half-second before someone decides whether to keep going.
The cost wasn't abstract: someone had to ride out and shoot footage at multiple locations, and the app carries video weight at first launch. On a one-engineer team that's a day of design traded for several days of production and a permanent asset pipeline.
I made this one on judgment and never isolated it. The welcome screen changed inside a release that changed everything else, so I can't tell you what the video was worth on its own.
Fork
A better static welcome screen, one day of work
Constraint
One engineer; no existing footage; first-launch payload
Call
Shot video, full-bleed
Trade
Production cost, an ongoing footage pipeline, and no way to measure it
Result
Unisolated - stated as judgment
Decision 3 - Reversal
Building the home screen around a tour that generates itself, and then deciding to undo it
The old home screen gave about 20% of its height to the logo, then filled the rest with six tiles that duplicated five of the six tabs in the bottom bar. Every route into the product existed twice and the first thing a returning rider saw was branding.
I rebuilt it around the single thing the product is for. Open the app and a new tour is already being generated from your location, the weather, nearby traffic, your preferences and your bike, with curated tours underneath and manual creation raised to the same level. The bottom bar went from six destinations to four - Home, Tracking, Logbook, Garage - which is the same decision stated in navigation rather than in tiles.
It does the magic thing, and it takes a few seconds. I had thought of those seconds as anticipation. They aren't. A rider standing next to a bike with a helmet in one hand, watching a loading state, isn't anticipating - they're deciding to put the phone away.
So the next release moves generation behind an explicit action the rider takes. It costs the product its best trick: nobody will receive a tour they didn't ask for. It ships for the 2027 season, and I don't have the numbers yet.
Fork
A tour waiting for you, or a tour you ask for
Constraint
Generation takes seconds - five live inputs, not a cache
Call
Shipped automatic. Judged it wrong. On-demand ships next season.
Trade
The unprompted magic moment, given up entirely
Result
Pending - next season
a) Six tiles, six tabs, five of it the same destinations. The logo takes up 20% of the screen. -> b) A personalized tour is generated as you open the app -> c) Next season, the option to generate a tour, or pick from selected suggestions.
Decision 4
Making the flagship sensor feature opt-in, and saying why out loud
Lean-angle and cornering capture was my engineer's idea and it's a good one - the phone's gyroscope and accelerometer can record how you actually rode a corner, with the screen off. I backed it and designed it in.
It is also battery-heavy and only produces real data if the phone is mounted on the bars correctly. Defaulting it on would have meant better data, a better demo, and far more riders using the newest thing we'd built.
I made it opt-in and put the mounting requirement in front of the rider before they enable it, rather than in a support article afterwards. Riders had already told us why: the ones who tracked were reporting phones running hot and draining. On a motorbike a dead phone isn't a degraded app experience, it's a navigation failure a long way from home.
Roughly 15% of riders turn it on. I'd make the same call again.
Fork
Default-on for adoption and data, or opt-in
Constraint
Battery draw; accuracy depends on correct mounting
Call
Opt-in, with the mount requirement surfaced first
Trade
85% of riders never use the flagship feature
Result
~15% opt-in rate
Decision 5 - Reversal
Instrumenting the ride, and being wrong about what was happening on it
Before scoping the redesign, the engineer and I went back through the previous season. Only about a third of started tours were reaching the server, and the app had no event for starting, cancelling or ending a tour - the only signal was a screen view and, eventually, a saved tour. You cannot diagnose a ride from that.
I had a theory. Abandonments clustered right after the start, which looked like people trying the app on the sofa rather than riding with it. It's a tidy story and it was wrong.
We shipped real tracking events in June. The answer came back in two weeks: of 512 tracking sessions, 51% finished and 38% aborted because the app could not get enough GPS. In the June sample, Android finished 3 of 30 sessions - and Android is 65% of installs. It was never an instrumentation gap. The rides were genuinely failing, on the platform most of our riders use.
The same location defect independently rejects around 90% of devices from the Coach feature's sensor check. One fix moves both.
Fork
Redesign against the hypothesis, or spend engineering weeks instrumenting first
Constraint
One engineer; instrumentation weeks are redesign weeks
Call
Built the events. My own hypothesis was the thing they disproved.
Trade
Engineering time that could have gone to features, spent on measurement
Result
A named, fixable platform defect instead of a plausible story
Once the events existed, the answer took two weeks. Android finished three rides out of thirty - and Android is most of our riders.
Decision 6
Pausing community in a product whose users are a community
Motorbike touring is social, and community was not just on the roadmap - it was half the old onboarding. Two of its four steps were spent recruiting new riders into groups and group rideouts, before they had seen a single road. We cut all of it.
At a few hundred monthly actives spread across several countries and concentrated into a three-month season, a community surface doesn't fail loudly. It fails quietly - empty feeds, unanswered posts - and makes a small product feel abandoned rather than intimate. Shipping it would also have spent our one engineer on the feature least likely to bring anyone back.
I made the call to pause it rather than cut it, and attached a population threshold instead of a date: 300 active users per country. We are not close. Naming the number was the point - it stops community being relitigated every quarter on vibes, and it means the feature returns when it can work rather than when someone has the energy to argue for it.
The trade is real: we gave up the one mechanic in the product that might have compounded on its own - and the threshold we set means we gave it up for longer than a season. What we bought was an onboarding that spends none of a new rider's patience on a room with nobody in it.
Fork
Ship community as planned, or hold it
Constraint
A few hundred actives, split by country, across a three-month season
Call
Paused, gated on 300 active users per country
Trade
The only self-compounding mechanic in the product
Result
Engineering time held for the core loop
Decision 7 — Settled, Option A
Putting a rider inside a photograph of a ride nobody photographed
Riders do stop to take pictures - of the pass, the valley, the bike leaning against a wall. What nobody has is a picture of themselves riding. You can't photograph yourself at speed, and there's rarely anyone at the corner to do it for you. So a rider's own record of a tour is scenery and a parked motorbike, and the app's contribution to it was a line on a map.
So I built the thing I wanted: a photorealistic image of the rider on their own bike - the right model, the right color where we know it - at real coordinates from their actual route, under the weather and light that were genuinely there for that time of day and that season. It was my idea and I wrote the prompt.
I chose not to label it as generated, on the reasoning that nobody would believe a photographer had been following them. I've come to think that reasoning was weaker than it sounded. It is obvious inside the app, where you just pressed a button. It is not obvious in a group chat, which is exactly where a shareable artifact is designed to end up - and every property I tuned for, the exact bike, the exact color, the exact place, the exact light, is a signal arguing that someone was there with a camera.
The feature has drawn little more than “that's cute”, and we never measured sharing. I'd build it again. We label it now.
Fork
The GPS trace and whatever riders photograph themselves, or generated imagery
Constraint
Riders don't photograph their own rides; a map line isn't a memory
Call
Photoreal generated imagery, unlabelled
Trade
An artifact that reads as evidence of a ride, outside the context that explains it
Result
Little reaction, unmeasured - and a labeling decision I'd now reverse
The system
One designer and one engineer rebuilt a product across iOS and Android in seven months, in five languages. That arithmetic only works with a system behind it.
I built a deliberately lean library in Figma - around 100 components - and translated it into Storybook, from which we built both apps in React Native. Lean was a constraint, not an aesthetic: every component I added was one an engineer had to maintain alone. Text components carry fluid height and layouts reflow around them, which is what makes five languages survivable when German runs a third longer than English and nobody is available to hand-fix a screen.
The one thing I refused to systematize was the routes on the map. Everything else is a component; a road is not a variant of anything.
We used AI throughout - translating the library into Storybook, writing and debugging against it, tracking the work in Linear. It is also where the project's most expensive surprise came from. Although text, spacing and color styles were all defined, the translation drifted: slightly different values landed across components, consistently enough to look deliberate and inconsistently enough to break the system. Catching it took thorough manual QA of every component. The system held because a person checked it, not because it was generated from a source of truth.
Small enough that one engineer could hold all of it. Every state specified, because there was nobody to ask at build time.
Outcome
What worked. Onboarding completion went from 17% to 63%. First app opens in June more than doubled year over year, 148 to 385. The May 2026 peak of 727 monthly actives beat the previous year's peak by 10%, and May, June and July all ran 56–89% ahead of 2025.
What didn't. Across a full cycle, monthly actives averaged 231 against 283 the year before - down 18%. Sessions per active fell from 12.8 to between 4.1 and 4.6. The step from opening the tracking screen to a saved tour went from 40% to 18%. More riders arrived, and each did less once they were there.
Where it stands. The company is still here and is spending this off-season on the fixes the season's data identified - starting with the location defect. Shipped: AI tour generation, a rebuilt manual tour builder, a new garage, a log book, tour photo and video sharing. Paused: community. Next: on-demand generation, and GPS.
The same number of riders reached the tracking screen in both Junes. What happened after it is the whole problem.
What I'd do differently
I spent seven months on the entrance and shipped instrumentation for the ride in month seven. The redesigns biggest single finding - that a third of rides never complete, and most of those die on GPS - was available in June and could have been available in January, because building those four events was a week of work.
I'd instrument the core loop before redesigning the way into it. You cannot prioritize what you cannot see, and I rebuilt the part I could see.
Credits
Mine:
Product strategy for the rebuild, IA, all interaction and UI design, the onboarding rebuild, the home screen, the component library, the analysis of the season's data
Also mine:
The prompt behind the generated ride imagery; the updated palette and its application across the product
Partners:
Jonas Mueller, full-stack engineer - built both apps, wrote the tour generation algorithm, originated the lean-angle capture, owned the tracking instrumentation; Axel Kleinberger, PM - the road footage, which he owned end to end;
Sarah Malli, marketing - the three-email relaunch, social media;
Remo Brunner, web development, media outreach
Not mine:
The tour generation algorithm - Jonas's. The brand identity, which predates me;
I updated the colors and how they're arranged, not the identity itself. The road footage - I had input, Axel owned it. The acquisition lift, which was marketing's.