Why a Composer Makes Apps — The Entry Point to MUED

I get asked that a lot, but I never have a good answer ready, you know?

I'm building a few tools for music production under a brand called MUED. There's MUEDnote for production logs, MUEDear for ear training, MUEDlobe for cognitive profiling, and MUEDial for online mixing.

Yeah, each one gets its own name based on what it does. The main one is MUEDnote—it records the decisions you make during production. Why you chose that tempo, why you went with that chord. That kind of thing.

Not even close. Originally I was trying to build an LMS—a Learning Management System—for music lessons.

I figured lessons were the one thing in music that actually worked as a business, right? When I was thinking about what to do next with my production company, that seemed like a natural starting point. And I was teaching programming on the side at the time—that's where I first came across the whole LMS concept.

Exactly. I thought, "Oh, so there's a system that lets anyone deliver consistent-quality lessons." I figured we could bring that into our music teaching and systematize the whole thing.

Honestly? I don't think music lessons themselves have that much value.

I'm not saying lessons are useless. But I went pro as a self-taught musician. No school, no mentor. What I actually needed wasn't lessons—it was a system that supports you while you teach yourself.

I just kept stripping features away. Auth, servers, payments—all the stuff I'd piled on over two or three years, I ended up removing all of it.

Because none of it needed to be built from scratch. Transcription? Whisper. Payments? Stripe. Scheduling? The OS handles it. Just use what already exists. The only thing worth building yourself is the stuff nobody else can replace.

Ear training and a blog.

That's it. But those two things can't be replaced by AI. Ear training is a physical skill—you can't ask AI to "train my ears" and actually get better. And the blog—the production log—is a record of your own decisions. The act of writing it is the whole point.

Don't make it sound cool. I was just wandering in the dark for two or three years.

Honestly, a lot of it has been a failure.

It was the first app I built, so I poured way too much into the philosophy—"why production logs matter," "why you need to put things into words.” The implementation didn't keep up. I can talk about the vision all day, but when someone asks "okay, but how does it actually feel to use?"—that's where it falls short.

Yeah, it does. But because MUEDnote failed, I was able to go all-in on simplicity with MUEDear—just "listen to A and B, pick the right one." And MUEDial I could boil down to "mix through chat.” Every time I build something new, I see what I should've done the last time.

Totally. If I'd only worked on MUEDnote, I'd still be polishing the philosophy while the implementation lagged behind. Building other apps is what finally taught me what "delivering something to users" actually looks like.

No way. Everything I learned by failing with the other apps feeds back into MUEDnote. MUEDear taught me "if the experience isn't simple, it won't land." MUEDial taught me "put the concept right there in the UI." It all circles back to MUEDnote. It just takes time.

You can tell when something's off.

Like, when I'm setting EQ boost amounts for ear training exercises, I can tell—"this is the kind of difference you'd catch on the spot in a session" versus "this one you'd only notice in a direct A/B comparison." I've been listening in studios for years. That ear is just there.

An engineer's app can be technically accurate, but it doesn't have the judgment of "does this difference actually matter in a real session?" You can't design that without hands-on production experience.

Take Jack Conte from Patreon. He was a musician in a band called Pomplamoose. His pain point was "I'm making these elaborate YouTube videos and I still can't make a living.” That's what drove him to build a monetization platform for creators. Conte partnered with an engineer he knew from Stanford. In my case, AI plays that role.

Someone from the field decides "we need this, we don't need that," and borrows someone else's skills for the implementation. I can't write code, but every product decision is mine.

At the core, I just love making things. It doesn't have to be music.

Yeah, I was moonlighting as a network engineer. Always been into tinkering with computers. A band guy whose side gig is network engineering—makes no sense, right?

Then I did the programming instructor thing. That's where I learned about LMS, and the seed for MUED was planted. MUED lives at the intersection of music expertise and programming literacy.

Big companies can build generic tools. But deciding whether "this EQ frequency range actually matters in a real session" or "would a pro hear a difference with this compressor setting"—that takes someone who's been in the room. That's what I'm betting on.

Marketing.

MUEDnote is kind of a weird app, you know? When you say "it logs your music production process," most people just go "...huh?" So I need a place to explain the intent. If I just wrote "it's an amazing app," it'd reek of marketing. This Q&A format lets me explain by being asked. ...Which, yeah, is itself a sneaky form of marketing.

Better to say it now than get called out later, right? But the thing is, when an AI keeps asking "why did you do that?", answers come out that I'd never thought about before. That whole "it's been a failure" thing earlier—I couldn't have put that into words if I hadn't been asked.

...Yeah. And this conversation is actually doing it better than MUEDnote can right now. Pretty ironic. I said the implementation hasn't caught up, and this article is basically a working prototype of what MUEDnote was supposed to be.

Yeah. So the fact that I'm admitting failure in this article—that itself feeds into MUEDnote's next update. Probably.