Tuneup

The High Cost of Drivetrain Maintenance

SRAM’s Eagle drivetrain has dominated the mid-to-high-range mountain bike market for nearly a decade. While the system has devoted fans, it comes with a significant drawback: replacement parts are expensive. A single cassette costs $200-$500.

Lifespan predictability makes the high cost even worse. Depending on riding conditions, maintenance habits, and how worn other drivetrain components are, a chain might last 600 miles or over 2,000 miles. Each drivetrain component wears at a different rate, and letting one part deteriorate too much drastically shortens the lifespan of the others.

After burning through components faster than expected, I wanted to understand exactly how long my parts were lasting and what I could do to extend their lifespan.

Existing Solutions & Opportunity

Even though my experience had been with the SRAM Eagle, most drivetrains share these characteristics and there were already solutions addressing component and maintenance tracking.

Two apps dominated this space: ProBikeGarage and Maintrack. Both offer comprehensive functionality: component profiles, automatic tracking via Strava GPS data, service reminders based on usage, and advanced features for those who swap parts for racing or indoor trainers.

Despite working like a 1900s Model T, the apps clearly provided value: ProBikeGarage alone had 100,000-500,000 downloads, nearly 2,000 Android reviews, a $4 iOS price tag, and roughly 20,000 new users in the past year.

Identifying the Gap

However, using these apps revealed significant usability friction:

• Functionally different pages used identical layouts. Looking at a component page felt the same as looking at a bike page, making it easy to lose track of where you were
• Visual indicators weren’t glanceable. Component icons and lifespan indicators were often indistinguishable from each other
• Common tasks required multiple steps, and actions lacked confirmation feedback, creating anxiety about making irreversible mistakes
• Advanced features appeared without context or explanation

The learning curve felt disproportionate to the value, especially for an app you might only check a few times per month.

Reading the Market Signal

Even with its usability issues ProBikeGarage got 4.6★(IOS)-4.8★(Android) ratings. Users were rating the solution highly and wanted the functionality badly enough to tolerate significant friction.

My hypothesis: Within the niche of people who fastidiously maintain their bikes, many users were bouncing during onboarding or abandoning after initial frustration. A tool with feature parity but substantially better execution could reduce this adoption barrier.

The cycling community is polarized around tracking, and I wasn’t trying to convince skeptics. Instead, I was betting that execution quality could capture more of the existing demand that ProBikeGarage had validated.

Working Within a Niche

Through conversations with cyclists and combing online forums, I realized that the most engaged people were already giving feedback in app reviews. Rather than chase broad validation, I focused on the demonstrated market and mined existing app reviews to extract:

• What users valued most in the solution
• New feature requests and improvements
• Specific UX pain points causing frustration
• Prioritization signals based on how frequently topics were mentioned

I reserved 1:1 interviews for usability testing, not concept validation. I tested task completion with 5 people who had varying levels of maintenance knowledge by simulating scenarios drawn from reviews and my own experience. This approach let me validate whether my design decisions actually reduced friction, even without access to an existing user base.

Design Strategy

My strategy was to provide core capabilities with improved execution, then once core needs were met, add more advanced functionality with real user feedback.

I worked through the core workflows using rapid wireframing, guided by patterns from app reviews and usability issues I’d identified. This process surfaced the main design challenges that stood in the way of improved execution

Designing the UX

Wireframing several iterations of core features, revealed a number of UX challenges with 4 that stood out as challenging:

• Structuring relationships between parts, bikes, and service records
• Implementing grouping with a simple mental model
• Building intuitive tracking rules without excess cognitive load

Relationship between parts and service

Initially, I placed components and service reminders in the same view. It seemed logical to show what maintenance was due for each part. This created immediate problems:

• Conflicting actions (editing a component vs. completing a service task required different controls)
• Selection logic broke down (how do you select only components or only service items?)
• Scalability issues (many components buried service reminders; many reminders overwhelmed the page)
• Component details were too extensive to show inline, complicating navigation and actions

I mapped out other possible architectures to solve these constraints:

Option 3 resolved the interaction conflicts by separating components and service reminders into distinct tabs. This created clear organization, prevented mixed list items, and made multi-select editing possible. I refined the design to support filtering, adding new components, and dedicated action buttons for each tab.

Implementing Grouping with a Simple Mental Model

Grouping is critical because parts can be assemblies that should be editable as one unit. For example, a wheel includes a hub, rim, and tire- it would be a huge pain to edit all of them separately.

But there are many valid ways to conceptualize groups, and they often overlap:

A cassette is part of the drivetrain (components that wear together as a unit), but it’s also attached to the rear wheel (components that move as one assembly). This raised questions about how accurately groups should mirror physical bike structure:

• Should groups nest inside other groups? How many levels? How do you show this on mobile?
• Can a part belong to multiple groups?
• Can a part be a group? Is a wheel a part or a group?

I looked for the mental model that provided the most functional benefit and realized the primary purpose of grouping is editing assemblies efficiently, with organization being secondary. That prioritization led me to structure groups as simple section headers with no nesting. This made removal, editing install dates, and applying tracking rules straightforward for groups while creating the simplest mental model to grasp.

Tracking Rules for Mixed Usage

Cyclists often ride indoors with their bike on a turbo trainer or swap wheels for different conditions. Without tracking rules, the app would incorrectly add mileage to parts that weren’t used.

The challenge was letting users track the right parts without making them solve logic problems or understand complex trigger conditions.

Strava (acting as a database for rides) has multiple trigger methods—bike profiles, activity types, and manual tags. GPS head units and indoor training platforms add more variables since you can set bike profiles before data syncs to Strava.

I split the problem into triggers (what type of ride?) and actions (should this component log mileage?).

Because there were many possible trigger methods, I used Strava tags as the default since they’re prominent in the interface and created documentation for edge cases with different tracking devices. I also mirrored Strava’s tag grouping to make the connection clearer.

For actions, I realized that including rides with a specific tag automatically excludes everything else.

This meant there were 3 distinct rule types:

• Log all rides
• Log only rides with X tag
• Don’t log rides with X tag

Users choose whether to include or exclude, then identify those rides with tags.

When a rule is set, an icon appears on the component card to indicate it’s not logging all usage.

Outcomes

The app is not yet in beta, so I have limited metrics. For now, here’s a cursory comparison of ProBikeGarage and Tuneup for three common actions:

Replacing a part

PBG: 5 steps | Tuneup: 3 steps

• Tuneup includes action confirmation and undo; PBG does not

Completing service

PBG: 4 steps | Tuneup: 3 steps

• PBG requires completing each service individually (4 steps per service)
• Tuneup allows bulk completion of multiple services at once

Grouping parts

PBG: 9 steps | Tuneup: 3 steps

• PBG only allows sub-parts (no separate groups), and each sub-part requires 9 steps to add
• Tuneup can group and ungroup multiple parts simultaneously