Frank
The first version was embarrassing. Not “needs some polish” embarrassing. Full “what the hell are you doing” embarrassing.
It was a single PHP page. Basically a glorified text-area with a button. I was generating Suno prompts by hand, tweaking them in a browser, copying the output, pasting it into Suno, listening, hating it, going back, and doing the whole thing again. Twenty minutes of nonsense for a sixty-second clip that might be good or might sound like a ringtone from 2004.
I built that ugly little page because I was tired of the friction. That’s it. No grand vision, no product roadmap, no “I’m going to build the ultimate AI music workstation.” I just wanted to stop doing the same dumb manual steps over and over.
Twenty-nine years in IT will do one thing to you without fail: it makes you allergic to repetitive manual processes. The same instinct that makes you write a PowerShell script to fix a thing instead of clicking through it four hundred times made me open a text editor and start hacking.
The stupid idea worked. And then it got complicated.
What I Was Actually Trying to Solve
I have over 4,000 songs on my Suno profile. I’m not a casual user who throws a prompt in on a Friday night and sees what happens. I work at this. I study how the model responds to style tags, tempo cues, instrumentation descriptions, genre hybrids. I’ve put in enough reps to have real opinions about what works.
And what I kept running into was a workflow problem, not a creativity problem.
Suno’s web interface is fine for getting started. It is not fine for doing serious, iterative, structured work at any kind of scale. You can’t save prompt variations side by side. You can’t test a genre hybrid prompt against a reference track structure. You can’t A/B a lyric approach. You just type, generate, hope, repeat. That’s a hobbyist workflow, and I was trying to do something more deliberate than that.
So the real problem I was solving was: how do I build a working environment around Suno that actually supports methodical creative work?
The answer turned out to be React, TypeScript, and more API integrations than I originally intended by a factor of about six.
How It Grew From One Bad Idea Into Something Real
Here is the honest version of how HookHouse-Pro came together, because the cleaned-up version is boring and also a lie.
I did not design it first and build it second. I built one thing, realized it needed another thing to not be useless, built that, realized that exposed a third problem, and kept going. It’s the same way I’ve approached every piece of software I’ve ever written, which is not the right way according to everyone who has taken a software engineering course. It is, however, the only way a self-taught guy with a full-time job and a home lab and a family actually ships anything.
The Suno Prompt Doctor came out of genuine frustration with prompts that were grammatically fine but sonically wrong. I needed something that could diagnose why a prompt was underperforming, not just rewrite it blindly. So I built a diagnostic pass first, then a rewrite engine, then a way to compare the original against the revision. That’s three features that came from one specific, recurring irritation.
VocalForge came from a completely different direction. I kept generating songs where the vocals were technically fine but felt disconnected from the instrumental bed. The prompt wasn’t doing enough work to tell the model how the voice should sit in the mix. So I built a tool specifically focused on vocal characteristics, delivery style, and the relationship between the singer and the track. Different problem, different tool, same app.
The 13 genre-specific seed generators came from something I noticed after probably 500 generations: certain genre combinations have structural requirements that generic prompts completely ignore. Southern rock needs a different kind of space in the arrangement than Minneapolis funk does. They’re not interchangeable frameworks. So I built seed generators that understand the DNA of specific genres instead of treating “rock” and “funk” as equivalent starting points.
Album Mode, MasterForge, MIDIForge, the Production Intelligence layer, the NGROK-based server admin section, the multi-API setup running OpenAI, Anthropic, Gemini, xAI, and Suno all wired in together. None of that was planned in session one. All of it came from actual use, actual problems, actual creative limitations I kept bumping into.
That’s the honest version.
What It Taught Me About How I Build Things
I’m a beginner coder. I’ll say that clearly, because the project description sounds more impressive than the person who built it probably deserves. I can make things work. I cannot always explain why they work in the way a real developer would. There are parts of the HookHouse-Pro codebase that I am mildly afraid to touch because I know they’re fragile in ways I don’t fully understand.
But here’s what the build process confirmed for me: I focus best when the problem is specific and the frustration is real.
I try to focus on what actually works instead of what sounds good online. Focus. Ha. If you know anything about ADHD and autism and a brain that has been running at full noise for 56 years, you understand why that sentence is funny to me. The concept of “just focus” has been a running joke in my life since approximately 1978.
What I’ve learned is that I don’t focus through discipline. I focus through irritation. When something bothers me enough, I can’t stop picking at it until it’s fixed. That’s not a productivity strategy I’d recommend to anyone. But it is, apparently, how I build software.
Every single feature in HookHouse-Pro exists because something annoyed me. Not because I thought it would be cool. Not because a tutorial suggested it. Because I was sitting there trying to do real creative work and the tool in front of me couldn’t keep up.
That’s a different motivation than building something impressive. And I think it’s why the app ended up being genuinely useful instead of a list of features with nothing underneath them.
The Difference Between a Portfolio Project and a Working Tool
I’ve seen a lot of developer portfolio projects. Side projects that exist to demonstrate a skill, get attention, and then get abandoned once the builder moves on to the next thing to demonstrate. Nothing wrong with that. But HookHouse-Pro isn’t that, and I know the difference because I use it constantly.
It’s live at hookhouse-pro.app. It’s running on my cloud infrastructure behind Caddy, managing real API traffic, doing real creative work. When I sit down to make music, this is the environment I’m in.
The fact that a 56-year-old self-taught IT guy from Gray, Georgia built a multi-API AI music workstation in React is either inspiring or absurd depending on your perspective. Both are honestly valid.
What I know is that it started because I was annoyed, it grew because the problems kept being real, and it ended up being the most direct expression of how I actually think and work that I’ve ever put into code.
The stupid idea was the right idea. It just took a while to figure out what it was really trying to be.
