Building RideNote: Choosing What to Build

This is the first post in a series where I’m documenting the entire process of building and launching a mobile app as a solo founder. Not the highlight reel version, the actual version. The decisions, the pivots, the things that work, and the things that don’t.

I want to explore a specific question: What can one person actually accomplish with modern AI tools? Where does AI help? Where does it fall short? What does the end-to-end journey of taking a product from nothing to launch actually look like when you’re doing it alone?

The project is RideNote, a mobile app for mountain bikers. Over the next several weeks, I’ll be sharing the full process: product planning, design, development, launch preparation, and what happens after.

Why Start a New Project

I had some holiday time at the end of the year and wanted to take on a quick build. Something I could complete in a few weeks. Throughout the year I’d built various web apps, but I’d never actually built a mobile app from scratch and put it in the App Store.

I’ve designed mobile apps before. I understand the systems, I’ve been exposed to App Store requirements, but I’d never gone through the full process of actually shipping one. With AI-assisted development, it felt like the right time to try.

I also wanted a real case study. Something I could point to that demonstrates how I think about product development, make scope decisions, and execute. Whether that leads to projects or employment or just serves as a creative outlet, having a documented end-to-end build felt valuable.

Why This Specific Idea

I’ve been thinking about this problem for years. I’m a mountain biker, and like most riders, I constantly adjust my bike settings: tire pressure, suspension, different setups for different trails. And I can never remember what worked.

I tried building a version of this back in 2023 using FlutterFlow. I designed it in Figma, built it out, even tested it with some riders on the trails. But the execution was off. I’d made it too technical, too focused on suspension tuning and optimization. It didn’t match how riders actually think about their bikes.

So I shelved it.

When I decided to take on a project this year, I came back to this idea because it checks a few important boxes:

• It’s a problem I genuinely have and understand deeply
• The solution can be simple, no need to overcomplicate it
• I’ll actually use the app myself
• It’s achievable in a few weeks

I wasn’t looking to revolutionize mountain biking or build the next big social platform. I just wanted to solve a real problem in the simplest way possible.

Validating the Idea

Before jumping into building, I wanted to validate whether this was actually worth doing. I’d tried once before and it didn’t work out, so I needed to understand why and whether a simpler approach would resonate.

I spent time researching with Claude, specifically using Deep Research and Extended Thinking. My initial prompt wasn’t perfectly structured, it was more conversational. Something along the lines of: “I have this idea for a bike settings app, is there a market for it? Can you validate where there might be a gap?”

The research process revealed something important. My original idea, the technical suspension tuning approach, was already being done by an app called Sagly. It’s data-driven, precise, genuinely useful for riders who want that level of detail.

But the research also showed that most riders don’t want that complexity. They don’t need graphs and optimization algorithms. They just want to remember what worked last time they rode a specific trail.

I gave Claude a list of aspects to research and asked it to spot gaps where we could enter the market. The answer was clear: simplicity and speed. Riders need something they can log in 60 seconds and reference in 10 seconds. No learning curve, no technical jargon, just a simple note-taking app purpose-built for mountain biking.

This made sense to me immediately. When you’re about to head out for a ride, you’re not opening a spreadsheet or diving into complex settings. You just want to know: what PSI did I run last time? Did it feel good? That’s it.

The validation gave me confidence because:

• The gap was real and specific
• The solution could be genuinely simple
• I could see myself using it
• It aligned with how riders actually behave

Why Document This Publicly

I have a lot of conversations with people about using AI, navigating new tools, and how to actually build things. People often tell me I should document this stuff, post about it, maybe make videos.

This series is my way of doing that. Instead of scattering insights across LinkedIn posts or leaving them in conversations, I want to build a corpus of real-world insights on my website. Tools, resources, thought processes, challenges, all of it.

This isn’t just theory or hot takes. It’s a real project with real constraints. What tools do you actually need? What experience is required? Where does AI help and where does it fail? What can one person reasonably accomplish?

If you’re interested in solo building, product development, or just curious what’s actually possible with modern AI tools, this series will show you the unfiltered version.

What’s Next

Now that I’ve validated the idea and committed to building it, the next step is defining what actually goes into version one. What features are essential? What gets cut? How do you make scope decisions when you’re working solo and want to ship in a few weeks?

That’s what I’ll cover in the next post: defining the MVP and figuring out what RideNote actually needs to be.