How I Built Audio2: A Non-Developer's Journey from Idea to App Store

This is the detailed follow-up to my launch post about building Audio2. Here's exactly how I went from "I wish there was an app that could..." to a live app on the App Store. You can download the app here.

The Foundation: Learning and Tools

Before doing anything, I had to learn the basics of how to build. I learn better while doing, so I needed just enough to get started, then have the ability to keep revisiting lessons to figure out where I was making mistakes. I didn't want to become a professional developer – I wanted to build enough knowledge to understand the framework I'd be operating in and the general milestones I needed to hit. I was OK carving a weird path between those milestone.

The Learning Path

I took two key courses that gave me the foundation I needed:

1. Create Your Dream Apps with Cursor and Claude AI This was my introduction to AI-assisted development. It taught me the fundamentals of how I’d be building and introduced me to a number of tools at everyone’s disposal today. My recommendation: Build a project while watching the course (I had 3 running simultaneously — only one of which ended up working). With each lesson, I’d find my confidence building.

2. React.js Learning Path The instructor in the above course recommended building in React, a language developed by Facebook. I followed the advice blindly for this first app. But as I was building Audio2, I wanted to better understand the code and structure. So I’d watch this course piecemeal as I was building to get a better sense of what I was doing. My goal was to understand concepts like components, state, and props so I could better guide the AI.

The Tool Stack (And What It Costs)

Building Audio2 required several paid services. Except for Apple, each of these has free tiers that’s more than enough to get you started. Here's the honest breakdown of what I’m paying:

• Claude Max (WAS Pro @ $20/month, now Claude Max at $100/month) My AI coding partner. Claude is genuinely incredible at understanding what you want to build and writing functional code. The Pro version gives you higher usage limits, which you'll need when you're iterating frequently. NOTE: I started using Claude Code and moved up a subscription. See more details here.
• Apple Developer account ($99/year) Required to publish on the App Store. This gets you access to App Store Connect, TestFlight for beta testing, and the ability to distribute your app.
• *Railway ($5/month) This is an inexpensive platform for managing cloud applications. I had to build a server to manage the audio for creating captions and Railway was the least expensive. NOTE: This is particular to my project and might not mean much for yours.
• *Cursor (WAS $20/month; NOW Free) This is your building app, specifically built for AI-assisted coding. It integrates directly with your favorite LLM (I now have it running Chat GPT5, which is outperforming Claude) and can see your entire codebase when making suggestions. Game-changing for maintaining consistency across your app. I tried VS Code, but it was clearly designed for real pros. And Windsurf seemed equivalent to Cursor, so I just stuck with what I knew.
• *Expo Application Services (EAS) (WAS $19/month; NOW Free) Expo is the platform I used to build and deploy the React Native app. EAS handles the complex build processes and makes it possible to test on real devices and submit to the App Store without drowning in configuration.
• AssemblyAI (Free for now) Assembly is the audio service I'm using to transcribe captions.
• GitHub (Free) I created my first GitHub repository to store my code. Version control turned out to be absolutely critical for this type of development.
• Canva (Free) Needed this to build the material for the App Store
• Gemini (Free) I found this to be the best LLM for design within the app.

Total annual cost: $1,359

*TOOL AND PRICING UPDATES: 1) EAS: I started on a paid plan with EAS, but realized I could move to free by leveraging EAS's over the air updates instead of frequent builds. 2) I added Railway to make captions work. 3) I realized that everything I was doing with Cursor I could do via Claude Code, Terminal, and TextEdit, so I stopped using it. 4) BUT I had to increase my Claude sub to the Max plan, though I'm hoping to take that down in times where the coding is less heavy. For more details on these changes: https://www.linkedin.com/feed/update/urn:li:activity:7370646708252405760

Essential Development Strategies

My first few projects were duds. I realized that I was trying to get the AI to do everything based on a big idea: “Create an app that turns video into 15 second clips” or whatever. Claude or Manus (another tool I tried but gave up on), would confidently get started, but the end result didn’t work as I envisioned it — if they worked at all. 

The better process was to treat this like a snow fort: I’d build foundations, test them for soundness, then keep moving up. Here’s how I did it.

Create a Project within Claude to be my HQ

This was absolutely critical: I created a dedicated Claude "project" that held all my app documentation. I'm a super user of Claude projects — anything I work on gets a project and this app was no different. Claude has memory limitations in individual chats, and when you hit that limit, starting a new chat is like having a new employee onboard who knows nothing about your project.

The project became my central repository for:

• What had worked and what hadn't
• Code patterns that were successful
• Architecture decisions and why they were made
• Current bugs and feature requests

Claude would frequently try to do something that didn't work, so I'd have to keep telling it to read the project documentation before coming up with solutions: "Go learn where you've failed in the past before trying this..."

Pro tip: When I sensed a chat was getting too long and the context window was about to close, I'd ask Claude to create comprehensive instructions for the next version of itself — like having an employee train their replacement. This handoff document would include the current state, recent decisions, and immediate next steps.

Pit Claude Against Cursor

I frequently used both Claude and Cursor to solve the same problem, then compared their approaches. This was incredibly valuable because:

• Different LLMs have different strengths
• Sometimes one would spot an issue the other missed
• Comparing solutions helped me understand which approach was actually better
• It prevented me from getting stuck in one AI's particular way of thinking

A good example: The next version of Audio2 will offer captions on the clips — but Claude and Cursor disagree on the implementation. I was able to get them to debate and ended up siding with Cursor (via its GPT5 agent, which is proving to be really good) — though Claude suggested some additions that Cursor had missed and that are proving necessary. The competition between them often led to better solutions than either would have produced alone.

The "Novice" Framework

From day one, I told Claude I was a novice - it's documented in my project files. Throughout development, I'd remind Claude: "Remember that you're an expert developer helping a novice. Is this how a real developer would build this?"

This simple framing revealed crucial insights. For example, it helped me realize that my 3,000+ line App.js file was exactly the kind of monolithic code that real developers would have refactored into components long ago. (It's still on my to-do list, but at least I know it's not best practice.)

But mostly, I'd just ask either Claude or Cursor constantly to gut check me based on what I was reading or hearing from real developers.

This novice framing also made Claude more likely to:

• Explain why certain approaches were better. Part of why I'm doing this is to gain new skills, so I love the learning along with the building.
• Suggest industry standards I wouldn't know about.
• Point out when I was doing something that would cause problems later.

The Development Process: Messier Than Expected

Here's what actually building Audio2 looked like, day by day:

Starting with Components

As I said, I stopped trying to build the entire app at once. Instead, I focused on one piece at a time:

1. Episode list – Just getting podcast data to display
2. Audio player – Basic play/pause functionality
3. Timeline scrubbing – The trickiest part, took multiple attempts
4. Clip selection – Adding start/end point markers
5. Video generation – The final and most complex piece

Each component started as a conversation with Claude: "OK, we’ve got the episode list locked. Now let’s work on the player." Then we'd iterate until it worked.

The Reality of Dead Ends — and Why You Need to Fact Check

AI will enthusiastically lead you down paths that don't work. I spent a few days trying to implement video generation with FFmpegKit. Claude breezily let me know this was the simplest and most common way to do what I wanted to do. It kept failing and Claude would tell me, “I see what’s happening!” and the write hundreds of lines of code that didn’t fix the problem.

I spent about 3 minutes on Reddit and discovered the problem: FFmpegKIt was no longer supported.  We pivoted to iOS screen recording instead.

Another week was lost on trying to parse RSS feeds manually with regex, when a simple library would have solved the problem in an hour.

Lesson learned: When things get overly complex, step back and ask if there's a simpler approach.

Pro tip: A cheat for me was to search GitHub and find projects in React that seemed to solve similar problems to what I was wrestling with. I'd ask Claude to read the project documentation, understand what that (real) developer had done and if there was anything for us to learn. "Go read this" became a common prompt vs letting Claude search the Web on its own.

The "Easy" Problem

Every LLM is optimistic — just totally sure of their problem solving abilities. Claude and Cursor's agent would confidently me you something would be "straightforward" or "just requires a few small changes." These are WARNING SIGNS! Just like in life, nothing is easy.

Budget extra time for everything, especially:

• File permissions on mobile devices
• Audio/video handling
• React hooks (might just be applicable to this project?)

As the app got more complicated, I had to spend extra time creating builds in EAS, as well, slowing down development. 

The Code Generation Trap

When something breaks, Claude's instinct is to rewrite more code. It will produce elaborate solutions that introduce new problems. I learned to be more directive:

• "Don't rewrite anything. Just tell me what you think is causing the error."
• "Show me only the specific lines that need to change."
• "Let's revert this change and try a different approach."

Git Branches: Your Safety Net

[9/7 update: This is not the safety net I thought it was. A warning about my own discovery here.]

This was crucial: I learned to create a new branch for every major feature attempt. When Claude led me down a rabbit hole (which happened regularly), I could nuke the branch and return to the last working version. I'm sure this isn't how real developers work, but I found I was losing valuable time adding layers to my shoddy work. It was like a cook who adds too much salt and tries to solve it by adding more and more other ingredients — better to just start over.

My GitHub branch names, now deleted, tell the story:

• audio-player-basic
• timeline-attempt-1
• timeline-attempt-2
• video-generation-ffmpeg
• video-generation-replaykit

I'm a big fan of throw away work. Nothing wasted: I learned with each attempt.

Set Strict Session Limits

Mission creep is your enemy. I learned to set strict limits on what I'd work on each session. Bug creep and feature creep are incredibly tempting when you're in flow state.

One night I fixed an issue where swiping back made the scrubber inoperable. Simple fix, worked great. Then I thought: "Oh, maybe I'll make the waveform animation a bit smoother while I'm here."

That "simple improvement" cost me another hour and broke several other things. The animation looked marginally better, but now audio playback was glitchy and the timeline markers disappeared randomly.

This is where having Git branches saved me. I decided to nuke all the changes, live with the janky animation, and go to bed knowing the app would at least work the next day. I could start fresh tomorrow with a working foundation.

Set boundaries for each session:

• Fix ONE thing at a time
• Don't add features during bug fixes
• Commit working code before attempting improvements
• Have a clear stopping point before you start
• When something works, resist the urge to make it "better"

The Human Element

While AI did the heavy lifting on code, the crucial decisions were still human:

• Choosing React Native over other frameworks
• Deciding on the specific user flow
• Simplifying features when complexity got overwhelming
• Knowing when to ship vs. when to keep building

The Apple App Store Reality Check

IMPORTANT: Don't underestimate the pain that is the Apple App Store. I didn't realize how much time it would take to get your app to Apple, fill out all the online paperwork, and then wait for review.

My first submission was rejected because the reviewer was worried that podcasters wouldn't want their content shared. I had to write a detailed letter explaining the importance of sharing clips as a way to get new listeners and drive engagement. Eventually got approved, but it took days of back-and-forth.

In fact, I worked on this article while waiting for version 1.2.3 to be approved by Apple. Just making artwork for the App Store was challenging – you need multiple sizes, proper descriptions, keywords, privacy policies. There's always something else.

Budget extra time for:

• App Store Connect setup and metadata
• Screenshot creation and description writing
• Review process (24-72 hours, sometimes longer)
• Potential rejections and resubmissions
• Version update approvals for every release

That said, they do give you this cool animation:

For Anyone Considering Making the Leap

You don't need to become a programmer. You need to become good at:

• Clearly communicating what you want to build
• Breaking complex problems into smaller pieces
• Testing and iterating quickly
• Knowing when to pivot vs. when to persist

Start small. My first successful component was just displaying text from a hardcoded list. Your first step might be even simpler.

Embrace the mess. Professional development is cleaner and more structured. AI-assisted development is exploratory and chaotic. That's okay – it's still productive.

The future belongs to people with good ideas who are no longer stopped by technical barriers. If you've got the idea, the tools are waiting.

Audio2 is available on the App Store. The complete codebase and development log are on GitHub for anyone who wants to see exactly how it was built.