5 things I learned building an app as a musician

I'm a guitarist and vocalist who also writes software. I built RunThrough because I wanted a practice recording app that didn't exist yet. Along the way I learned some things I wasn't expecting, not about code, but about practice, building things, and what happens when you're both the developer and the user.

1. The feature I thought mattered most wasn't the one that mattered most

When I started building RunThrough, I was obsessed with the A/B comparison feature. Side-by-side waveforms, instant toggling between two takes. I was sure that was the thing that would make people care.

It is a great feature. But the thing I use most often, and the thing testers mentioned first, was just how easy it is to start recording. One tap. No setup, no project files, no choosing an input. Just hit record and play.

I'd been so focused on the comparison that I almost treated the recording part as a given. Turns out, if recording is annoying, nobody ever gets to the comparison. The unsexy part was the foundation.

2. Musicians and developers think about iteration the same way

In software, you ship something, see how people use it, see what’s broken, and you improve it. You don't try to get it perfect before anyone sees it. You build, test, adjust, repeat.

Good practice works the same way. You play a section, record it, listen back, identify what's off, and try again. The loop is almost identical. Record, compare, adjust. Ship, test, fix.

I didn't plan this connection. It just became obvious once I was doing both things every day. The mindset that makes someone a decent developer is weirdly similar to the mindset that makes someone a good practicer. Both require you to be honest about what's not working and specific about what to change.

3. Building for yourself is harder than building for "users"

When the user is some abstract person, you can make assumptions about what they want. When the user is you, sitting on your couch with a guitar, those assumptions get tested immediately.

I'd build a feature, use it during practice that evening, and realize it was wrong. Not broken, just wrong for how practice actually works. The flow was off, or it took too many taps, or it interrupted the thing I was doing. I threw away more work than I shipped because of this.

That was frustrating, but it also meant the app ended up shaped by real practice sessions instead of guesses about what practice sessions look like. Every screen in RunThrough exists because I needed it while holding a guitar.

4. Nobody wants another app

This one took a while to accept. Musicians don't wake up thinking "I need a practice app." They wake up thinking "I should practice more" or "why am I not getting better." The app is a tool, not a goal.

I had to stop thinking about RunThrough as a product and start thinking about it as an answer to a question most musicians are already asking: is my practice actually working?

That reframing changed how I talk about the app, how I designed the onboarding, and what I prioritize in updates. The app isn't the point. Hearing whether you're improving is the point.

5. The tape doesn't lie, about code or music

The best thing about recording yourself is that it removes opinion from the equation. You either nailed the timing or you didn't. The tone is either clean or it isn't. There's no arguing with a recording.

Building software is similar. The app either works or it doesn't. The feature either helps people practice or it gets in the way. Every change is recorded in Git for all time. User testing is the developer's version of listening back to a take.

I've gotten better at guitar since I started building this app, partly because I practice more consistently now, but mostly because I listen back more. The app forced the habit. And the habit forced honesty about where I actually am versus where I think I am.

That's the whole thing, really. For music and for building software. Be honest about where you are, be specific about what needs work, and keep showing up.