It started with a favor. A friend of mine - an actor - needed a website for casting submissions: headshot, bio, credits, a couple of reel links, nothing fancy. I built her one in an afternoon and put it on my own hosting.
Then I did the thing every developer does at some point: I looked at that one-off site and thought, I could turn this into a product.
Actors need this constantly. A resume site is table stakes for casting submissions, and most of the alternatives are either generic website builders that weren't designed for the format (Squarespace, Wix - overkill, and priced like it), or casting-platform profiles (Actors Access, Casting Networks) that aren't really a website, just a listing inside someone else's walled garden. Nobody's built the simple, purpose-made version: pick a name, fill in your info, get a real page you own the link to.
So that's what I'm building. It's called MyStageBio. Every performer gets a subdomain - yourname.mystagebio.com - with an admin panel to manage their own bio, headshot, credits, and reel links, no code required. Free-to-start demo, paid to keep, custom domain support if you want one.
Why "with Claude" is the actual interesting part
I'm not a stranger to building web apps - the portfolio on this site has a few of them. What's different this time is how much of the actual construction - the PHP, the MySQL schema, the Stripe integration, the security hardening - happened in conversation with Claude rather than me writing every line myself.
That's not the same as "AI built my SaaS," which is the kind of claim that's usually followed by a demo that falls over the moment a real user touches it. What actually happened was closer to working with a very fast, very literal engineer who needed the architecture decisions made by a human and then executed them well: multi-tenant database design, subdomain routing by Host header, tenant data isolation, a demo-then-pay account lifecycle, Stripe Checkout and webhooks, rate limiting, CSRF protection, email verification. All of it exists, none of it is a toy.
I'll be writing about the specific decisions as I go - why I stuck with my existing shared hosting instead of reaching for a fashionable serverless stack, how the database is structured so one tenant can never see another's data, where AI actually belongs in a product like this (hint: not where you'd guess), and eventually the real numbers - what it costs to run per month, in hosting and in API calls.
The part I'm being honest about upfront
This is a side project, not a full-time pivot. The entire premise, from a business standpoint, was minimizing ongoing time commitment: reuse hosting I already pay for, build one shared template instead of a bespoke site per customer, and keep AI as a light one-time assist during signup rather than something the live site depends on. If a feature needed a lot of my ongoing attention to keep running, it mostly didn't make the cut.
Whether that discipline holds up once real customers start hitting edge cases - that's exactly the kind of thing worth documenting honestly rather than glossing over. So that's the plan for this series: not a highlight reel, a build log.