My Attempt to Build a Music Tutoring App Using AI Tools
The Spark of an Idea
As someone learning drums, I found myself wanting a better way to connect with my instructor outside of our weekly lessons. I wanted to track my progress, share practice videos, and get feedback - similar to the way I interact with my fitness coach using various tracking and messaging tools. It seemed obvious that music tutoring deserved the same level of structure and tech support. So I decided to build an app for it.
The catch? I’m not a developer. But we live in the age of AI-powered app builders, so I dove right in.
Exploring AI App Builders
I started by experimenting with a few popular tools that promised to let "non-technical" users build fully functional applications: Bolt.new, Lovable, and a couple of others. Their pitches were clear: describe what you want to build, and they’ll generate your app for you. Perfect.
My goal was modest: create a space where I could log practices, upload media, receive comments, and keep a lesson calendar. It didn't sound too complex, and I hoped these tools would get me at least to an MVP.
Early Wins: It Felt Like Magic
To be fair, the early steps felt incredible. I typed in my idea, described user flows, and watched as the tool produced UI layouts, navigation, and working buttons. With Bolt.new, I could even ask for a PRD based on the app I was building. That was wild.
The process made me think faster and visualize better. And when I was clear about what I wanted, the AI worked surprisingly well.
And Then... Reality Hit
But as soon as I needed my app to go beyond the screen and into real user functionality - storing practice logs, uploading video recordings, managing authentication - I hit roadblocks. Most of these tools assume some technical knowledge, even though they say they don’t. Connecting to a database, setting up Supabase, debugging why something isn’t saving correctly... it gets messy fast.
I ended up spending hours trying to figure out what went wrong, and sometimes helping the AI tool debug itself. I have a QA background, so I managed. But a truly non-technical user would have quit long before that.
Two Clear Use Cases Emerge
Through the process, I began to see two distinct ways in which these AI app building tools can (and should) be used:
1. Mockups & Prototypes
This use case is gold. If you have a vision for a product, you can describe it in detail to these tools and within minutes get a working prototype. It may not be usable by real users yet, but it's concrete and visual. It replaces the need for early wireframes and can even disrupt how product/design/engineering teams collaborate.
2. Personal Use Functional Apps
This is the holy grail - allowing non-developers to build fully usable apps for themselves or their business needs. But here, the tools largely fall short. Going from a pretty prototype to a working app with authentication, backend logic, data persistence, and media handling? That’s where the dream starts to break down.
Takeaway
This journey has shown me that the current AI app builders out there are incredible, mainly as prototyping tools. They can accelerate the product development process and help communicate vision across teams. But they’re not yet ready for everyday users who want to build fully functional apps without dealing with some technical aspects or needing prior software development concepts knowledge, at least to some extent.
Until these tools truly abstract away the complexity of databases, authentication, and debugging, they’ll remain best for mocking things up - not for launching products.
In the next post, I’ll dive into the biggest challenges I encountered, and why I eventually gave up on one of the tools entirely (at least for now).
So… What Does This Have to Do with Product Operations?
As I was building my own app - not just imagining it, but actually trying to make it happen - I realized how similar this process is to the heart of Product Operations work.
Trying out tools, understanding their capabilities and limitations, defining what success looks like, spotting friction points, and making decisions accordingly - these are exactly the kind of behind-the-scenes, high-leverage activities that Product Ops thrives on. It's not just about the tools, it's about creating the conditions for product teams to move faster, smarter, and with less friction.
A Product Ops mindset means being curious enough to experiment, structured enough to evaluate, and strategic enough to turn those insights into scalable systems. Whether it's setting up internal workflows, defining a feedback loop, or choosing which platforms will help your product org run smoother - the goal is the same: free up your product people to focus on product.
In this case, the experiment was personal - but the process, the way of thinking, was 100% Product Ops.
