Building Tools You Wish Existed

I didn’t set out to build software. I set out to solve a problem: there was no good way to search for orchestral works by Latin American composers, filter by instrumentation, and find rental materials — all in one place.

So I built OpusGraph.

This is not a story about becoming a developer. It’s a story about what happens when you take your domain expertise seriously enough to build the tool that doesn’t exist yet.

The Musician’s Advantage

Musicians — conductors especially — develop a particular kind of systems thinking. You learn to manage dozens of simultaneous variables: tempo, balance, intonation, phrasing, energy, timing. You learn to hear what’s missing. You learn to diagnose problems by their symptoms.

These are exactly the skills that make someone effective at designing software. Not writing code (that’s a different skill, and one that AI is rapidly commoditizing) — but understanding what needs to exist and why.

The Build-or-Buy Question

For most problems, the answer is obvious: buy. Use existing tools. Don’t reinvent wheels.

But there’s a category of problems where the existing tools don’t work because they were built by people who don’t understand your domain. Library management software built by people who’ve never run a music library. Scheduling tools built by people who’ve never coordinated a rehearsal schedule across three venues and sixty musicians.

When you hit that wall, you have two choices: adapt your workflow to someone else’s assumptions, or build something that fits.

What I’ve Learned

After building several tools and client sites, a few patterns have emerged:

1. Start with the workflow, not the interface. The best tools are invisible. They fit into how people already work, not how a designer imagines they should work.

2. Domain expertise is the moat. Anyone can build a CRUD app. Not everyone can build a CRUD app that understands the difference between a rental set and a purchase score, or why a conductor needs to see instrumentation at a glance.

3. Ship early, learn fast. The first version of OpusGraph was embarrassingly simple. It was also immediately useful, which told me I was solving a real problem.

4. AI changes the economics. Tools that would have taken a team of five engineers eighteen months can now be prototyped by one domain expert in weeks. This is not an exaggeration. It’s the current state of the field.

The Invitation

If you’re a musician, arts administrator, or nonprofit leader sitting on a problem that no existing tool solves well — you’re closer to building the solution than you think. The barrier isn’t technical skill. It’s the willingness to take your own expertise seriously enough to encode it.

The tools we wish existed are often the ones only we can build.