Building a podcast website in two weeks with Claude Code: The Mothership

The site for The Mothership with Daphne Oz went live on Oct 1, ahead of the show itself. The trailer is out now, and the weekly episodes follow. The site is ready for them: episode pages, show notes, every place to watch and listen, a newsletter, and a contact form.

Design and development took about two weeks. The code went from its first commit to launch in five days.

A few years ago I would have quoted that project at two or three months and a small team. So the question I keep coming back to isn’t whether AI can build a website. It’s what had to be true for this one to ship that fast without cutting the parts nobody sees.

The stack, and the job each piece does

I picked every tool for one job, and I picked the ones that let a small team run the site after I hand it over.

Claude Design let us skip the slow part of design and get straight into the real thing. We worked through home page directions, wireframes and a brand guide, and the client team opened each one from a shareable link and left their comments right on the design. No exported PDFs, no feedback threads to untangle. By the time anyone wrote code, the expensive arguments were over.

Claude Code did the building, and I did the directing. That distinction matters. I wrote the spec, kept a decisions log, and approved what shipped. The AI was fast because the instructions were specific, and the instructions were specific because the design and decisions were already made.

Sanity and Flightcast split the content cleanly. Flightcast hosts the audio and publishes the feed. It has no API, so a scheduled job on Netlify reads the feed every 15 minutes and creates drafts in Sanity, never live pages. A person adds the show notes, guests and artwork, then publishes. If the feed fails three times in a row, the system flags it and sends an email. Publishing refreshes the site in about seven seconds.

Accessibility was a requirement, not a phase

The brief set WCAG AA from day one: 4.5:1 contrast, nothing under 12px, generous touch targets, a visible focus ring, a skip link, one heading per page, and respect for reduced motion.

Then we tested it like we meant it. The first automated scan found no violations on any of the nine routes, at desktop or phone width. The launch QA went further: 23 browser and device setups, a 320px phone, keyboard-only use, text spacing, and a simulated high-contrast mode, measured against WCAG 2.2 AA.

That pass caught things a scanner never will:

• The Listen menu now closes with Escape.
• The scrolling topic ticker got a pause button. A loop you can’t stop fails WCAG at the most basic level.
• An autoplaying hero video with no pause control became a still image. That fixed an accessibility issue and cut the home page from 1.7 MB to 0.47 MB.
• A few small gold labels and numerals were lightened until they passed contrast, and the smallest text moved up to 12px.

The next step is a pass with real screen readers on real devices. Automated tools and emulators get you most of the way. They don’t get you all of it.

SEO, for search engines and for AI answers

A podcast lives or dies on being found, and today “found” means two audiences: search engines and the AI tools people now ask instead.

• Structured data on every page: the podcast series, each episode as a podcast episode and a video, the host as a linked person, and breadcrumbs.
• A sitemap built from the CMS, with image and video entries, refreshed whenever something is published.
• AI crawlers welcomed on purpose. The robots.txt explicitly allows the search and answer bots from OpenAI, Anthropic and Perplexity, and the site publishes an llms.txt file describing the show.
• IndexNow pings search engines the moment a new episode is published.
• Every page renders on the server, and the build fails if any page grows past a size budget.

A dedicated SEO and AI-discoverability audit before launch found six gaps, from a missing logo in the organization data to the About page missing from the sitemap. All six were fixed before launch. Lighthouse SEO scored 100 on every page at launch.

Security by design

Most of the security on a site like this is decided by what you choose not to build.

• The contact form stores nothing. Messages go straight to email through Resend. There is no database of visitor names and emails to leak.
• Spam can’t ride along. A hidden honeypot field, a fill-time check and a rate limit stop bots, and the thank-you email never repeats the visitor’s message, so the form can’t be used to relay spam.
• Every webhook is signed. The publish hook that refreshes the site rejects anything without a valid signature.
• Secrets live only in the host’s environment settings, never in the code.
• Least privilege throughout. The feed job uses an editor-level token, and the people publishing get editor access, not admin.
• Consent is enforced, not decorative. Analytics and session recording load only after a visitor agrees in the CookieYes banner.

One lesson from launch week: the consent banner turned out to be the slowest thing on the page on a phone. We redesigned it to be compact on small screens. Privacy tools are part of your performance budget now, so measure them like everything else.

Why this wasn’t possible a few years ago

The speed came from AI, but the result came from everything around it.

Five years ago, a site like this meant a designer, two developers and a QA lead for two to three months. This time it was one practitioner directing AI through a disciplined process: a design settled before code, a written spec, a decisions log, every change through a pull request, and real testing before launch.

The moment that mattered most came when Daphne saw everything put together for the first time. She was thrilled, and what she singled out wasn’t the gold lettering or the motion. It was how well every piece had been pulled into one clear whole, and how smart the choices behind it were. That is the part no tool does for you.

AI didn’t remove the hard parts. It removed the waiting between them. That is the same lesson I keep learning everywhere else: the constraint is never the technology. It’s knowing exactly what to ask for, and having the standards to check what comes back.

See it live at mothershippod.com.