I bought the bassists.com domain in 1999. I knew what I wanted to build, but the web wasn’t ready. No video, no music APIs, no song samples. Then I got busy with other things: Squidoo, No Treble, and client work.
When No Treble was acquired in 2025, Bassists.com came back to the front of my mind.
Prototyping the initial WordPress build with Claude Chat
In 2025, I started tinkering again. I had a clear picture of what I wanted: a music discovery site centered on bassists, but built for music fans. Each profile includes a bio, genres, associated bands, a curated discography, news, and videos. Start with a bassist you know, or search for a band, and follow the threads. The discovery is about the music.
I built the prototype in PHP, using Claude’s chat interface to help with the more complex parts. If you’ve ever used an LLM chat for coding, you know the workflow: upload a file, get a rewrite, copy it back into your project, re-run it, find the next issue, upload again. It worked, but it was slow. Even with all the copying and pasting, it saved me hours compared to the old workflow: Google searches, forum posts, WordPress documentation, and trial and error with solutions that didn’t work or were beyond my knowledge. Any developer dealing with a hard problem pre-AI knows that loop.
The prototype worked, though. And my intent from day one was to build the real thing on WordPress.
Why the scope document is the ultimate Claude Code prompt
When Claude Code came out, I was skeptical. But I decided to try migrating the PHP prototype to a full WordPress site. I approached it the way I’ve approached every web project for the last three decades: I wrote a scope document.
I’ve written a lot of scope documents. For clients, for development teams, for myself. I knew exactly what I wanted: custom post types for Bassists and for Bands and Artists, custom taxonomies, which post types would be public-facing and which were internal, and how they needed to relate to each other. A bassist has to connect to the bands they’ve recorded with. That relationship isn’t a taxonomy. It’s a direct association, and it has to work in both directions.
The scope document covered everything I’d bring to a developer: leveraging WordPress Core, avoiding plugins for core functionality, how the admin editing experience needed to work so anyone who understands the content could manage it without training, the nuances of my custom post types and taxonomies. Where I was unsure of the best method, I flagged it. For caching, I described the behavior I wanted: serve a stale cache to the current visitor and refresh it for the next one. I didn’t know if that was even a thing. Claude Code told me it was, gave it a name (stale-while-revalidate), and implemented it. I did this throughout the document: here’s what I want, here’s what I know, here’s where I need you to validate or fill the gap.
Then I gave Claude Code two things: the scope document and the folder with my working PHP prototype.
Here’s the (truncated) opening prompt I gave Claude Code. The real work was in the scope document and the prototype. The prompt just pointed to them.
I've been working on a prototype (in PHP) for a new site I want to build. Now I'm ready to make this a WordPress theme, and I need your expertise to build it and code it. [...]
I shared a folder with you that includes my working PHP site, the folder where the WordPress theme files will go, and the complete scope doc. [...]
Review Before we begin, I want you to thoroughly review the files to get a sense of what I have, and then:
1. Tell me what you see in succinct, but thorough bullet points
2. Ask me questions about anything you see in what I provided
Once we've reached a consensus on 1 and 2, I want you to outline the proper roadmap and methods for getting to a WordPress theme.If I had hired a team for this project, the proposal would have been in the five figures. That’s not a knock on agencies or developers. If money were no object, I would have been happy to collaborate with talented people who have those skills. But this was a passion project with no business model behind it. Spending five figures on a project like that was never realistic, and that’s part of why it sat for so long. Without AI, my only option would have been grinding through it myself over weeks or months, figuring out each piece through trial and error.
Claude Code removed a cost barrier, not a team. It gave me access to development capabilities on my own schedule for a project I’d been sitting on for 27 years because the conditions never lined up: the web wasn’t ready, I wasn’t available, and doing it alone would have taken months I didn’t have.
From prototype to functional WordPress site, the build took a weekend.
What Bassists.com looks like today
Bassists.com is a music discovery site. Each profile includes a bio, genres, associated bands, a curated discography, news, and videos. The web is noisy, and I wanted to build something where a strong taxonomy does the work: start with a bassist you love, follow the threads through genres and bands, and discover something new.
At launch, there were about 30 bassists on the site. Early visitors averaged 7.5 pageviews per visit, which told me the discovery loop was working. The catalog has grown steadily since then.
I’ve been playing bass since I was 10. Shining a spotlight on bassists has long been at the center of my life and career. It took 27 years, but it’s here.
