RideNote

Project Overview

RideNote exists to answer one question in a parking lot: was it 26 or 28 PSI that felt better last month? I designed, branded, and built it solo, end to end, to prove full product ownership in a real release context, not a prototype. This case study covers the product and development decisions; a separate design case study will go deeper on branding, iconography, and interface craft.

Tools & Technologies

The Challenge

Planning: The PRD as Self-Contract

I started with a comprehensive Product Requirements Document. Not a formality, a contract with myself to prevent feature creep.

The PRD defined success metrics, user personas, and most importantly, what I would NOT build. Every time I wanted to add a feature during development, I had to justify it against this document. Most times, I couldn’t. Social sharing, AI recommendations, Strava integration, all parked in Phase 2.

The primary persona was clear: “Weekend Warrior Matt,” someone who rides 2-4 times per month on a trail bike, uses Strava comfortably, but doesn’t want to become a suspension engineer. He just wants to remember if 26 or 28 PSI felt better last month.

Design + Development: Building in Code

I didn’t wireframe in Figma. The approach was PRD-driven direct implementation using Cursor AI. Unconventional, but it works for solo projects with clear scope and well-understood user flows. It wouldn’t scale to team environments where you need shared artifacts, but here it meant I could iterate fast.

Cursor handled boilerplate code, feature generation from clear prompts, and build debugging. But it couldn’t make UX flow decisions, design polish choices, or scope prioritization calls. Those required human judgment at every step.

The Context-Switching Reality

Solo building means constantly switching between brand design, UI design, UX thinking, development, and go-to-market. AI helps with execution speed, but the cognitive load of wearing every hat is real and under-discussed in “I built X in a weekend” posts.

My approach was to batch similar work: one day for brand, one day for UI implementation, one day for App Store prep. It reduces thrashing, though it doesn’t eliminate the mental overhead entirely.

Key Decision: Offline-First Architecture

The most impactful technical decision was making RideNote completely local. No user accounts, no cloud sync, pure SQLite storage on device.

Partly pragmatic (faster development without a backend) and partly philosophical (better UX with instant saves, works on trail rides with no signal, privacy by default). The trade-off, no cross-device sync, was acceptable for V1.0.

The payoff was immediate. Beta testers specifically called out how “smooth” the app feels. No loading spinners, no network errors, no sign-up friction. Everything just works, instantly. When you’re in a parking lot after a ride logging settings before you forget, that speed matters.

Key Decision: Baseline vs. Ride Note Mental Model

Early versions mixed two concepts that confused users: bike configuration (hardware capabilities) and baseline settings (what you typically run).

I separated these into distinct concepts. Your baseline is your typical starting settings, stored once per bike. Ride notes are deviations from that baseline, with performance feedback attached. Users understand they’re tracking experiments, not documenting a spec sheet. The mental model became clearer immediately.

Key Decision: Three-Dimensional Feedback

Instead of a single “How was the ride?” star rating, I added three sliders: Grip, Feel, and Control. Each on a 1-5 scale.

Tire pressure affects grip differently than suspension affects comfort. A single rating loses that nuance. The three sliders take about 10 seconds to adjust, fast enough to not feel burdensome, detailed enough to be useful when reviewing past rides.

Beta testers said this was the feature that made RideNote feel purpose-built rather than generic. A small detail that signals the app understands mountain biking.

Technical Challenge: The Slider That Kept Breaking

A React Native slider component worked perfectly in development but caused Expo builds to fail every time. Each cloud build took about an hour, so failures were costly.

The slider required React Native Reanimated v5, but Expo’s cloud builds used v3. The fix was a preflight script that checks critical dependencies before each build, catching issues before wasting an hour on a failed build.

Small fix in retrospect, but it saved hours. AI can help debug once you know what’s broken, but recognizing the constraint requires experience.

App Store: First Submission

First submission was rejected. Two issues: config file had iPad: true for a non-iPad app, and iPad screenshots were accidentally included. Straightforward fix, config change, screenshot removal, resubmit. Approved in two days.

While waiting for approval, I added three features users had mentioned: a pre-ride checklist, free-form notes, and custom checklists. These made the app more flexible without adding complexity to core ride tracking.

Beta Testing & Feedback

I tested with mountain biking friends, informal conversations after rides, handing them my phone and watching them use the app.

Feedback was consistent: “works smooth” and “looks premium.” The offline-first architecture paid off. No one ever saw a loading spinner. The brand execution exceeded expectations for a first version.

Testing also caught language inconsistencies. Early versions used “ride logging” language like Strava, but users weren’t logging rides. They were tracking bike setups. That subtle framing shift made the app’s purpose clearer.

Results & Impact

Reflection: What Worked

The PRD as a self-contract kept me disciplined. Writing down what I would NOT build was just as important as defining what I would. The offline-first architecture compounded benefits over time: faster development, better UX, simpler privacy model. Good architectural decisions make later decisions easier.

AI tools sped up execution significantly. Cursor helped me build features in hours instead of days. Claude helped with product strategy and marketing copy. But the real value came from using AI strategically, not as a replacement for thinking.

Reflection: What I’d Do Differently

I waited until the app was “done” to get beta feedback. Should have shared rough builds much sooner. Early feedback would have caught the “ride logging” vs. “setup tracking” language issue weeks earlier.

I didn’t document technical decisions as I went, which meant reconstructing context for this case study. A quick decision log would have helped.

I mixed App Store prep with bug fixes, which was inefficient. Screenshots and copy writing require a different mindset than debugging. Should have blocked a full day just for submission assets.

What’s Next

Short term: recruiting beta testers from Reddit and Pinkbike mountain biking communities. Validating whether the baseline + ride note model helps riders remember settings over time.

Longer term: freemium model with a free tier (one bike, last 10 ride notes) and premium features (unlimited bikes, full history, cloud sync). Exploring voice notes as a quick logging option for premium, capture thoughts immediately after a descent without typing.

A detailed go-to-market case study will follow once there are real metrics to analyze.