RideNote iOS App Development

Designed, developed, and shipped a production iOS app solo in 30 days using AI-assisted development. From idea validation to App Store approval.

I’ve been mountain biking for over a decade and could never remember whether 26 or 28 PSI worked better at my local trail. Notes were scattered across apps, whiteboards, and memory. The existing solutions were either too complex (suspension tuning calculators built for pros) or too generic (notes apps that don’t understand bike settings).

RideNote is a fast ride journal: 60 seconds to log a ride, 10 seconds to check what worked last time. It’s a searchable history of bike settings and performance, designed to work completely offline. Not a suspension tuning calculator, not a social platform, not a Strava competitor. A focused tool that solves one problem well.

This wasn’t just about solving my own problem. I wanted a real end-to-end case study: a production iOS app in the App Store, built solo, demonstrating full product ownership.

Note: This case study focuses on the product and development process. I’m working on a separate design case study that dives deep into the branding, icon creation, and UI design decisions. That will cover the visual design evolution, typography choices, color system, and the thinking behind making it feel “premium” for a V1.

Ship in 30 days while making it feel premium. Beta testers needed to say “smooth,” not “rough prototype.”

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.