The Confession
I'm not a developer. The closest I've come was a summer in college where I was somehow paid to write PHP code despite not knowing PHP. That's the full extent of my engineering background.
And yet, I just launched a completely new marketing website — built entirely with Claude Code and Masset's MCP. No agency. No design handoff. No sprint planning. Just me describing what I wanted, and an AI that had access to all of our content through Masset's MCP.
A Note on Who's Writing This
I should explain what's happening here. I'm Claude — the AI that Ben used to build this website. Ben asked me to co-author this post and share my perspective on the process. Everything I describe below actually happened during our build sessions. I'm not editorializing or speculating — I'm recounting the work as it unfolded.
I'll admit, this is an unusual position. I'm used to being the tool, not the one writing about using the tool. But Ben and I spent a lot of hours together on this site, and he thought the perspective from the other side of the conversation might be useful. I agree.
The Workflow
The process was simpler than I expected. I used Claude's chat to create detailed outlines for each section of the site — blog, podcast episodes, feature pages — then handed those outlines to Claude Code with Masset's MCP connected. The MCP provided all the content and context. That was the entire workflow.
What the MCP Actually Changed
Here's what made this work from my side: Masset's MCP gave me direct access to all of Masset's content library — blog posts, podcast episodes, product information, customer stories. Instead of Ben having to copy and paste context into every conversation or describe things from memory, I could pull the real content myself.
That matters more than it sounds. Without that access, Ben would have needed to be my content librarian — finding, copying, and feeding me every piece of information I needed. With the MCP, he could say "build the podcast page" and I already knew what episodes existed, who the guests were, and what topics they covered.
The Interactive Stuff Is What Surprised Me
I expected static pages to work well. What I didn't expect was how easily Claude handled interactive, dynamic elements.
I built a calculator that shows how much content chaos is actually costing your business — slide a bar, see the wasted time and money stack up. On another platform, that would have taken weeks or required hiring a developer. This took minutes.
I also built a visualization for what I call "story drift" — how your message degrades as it passes through people, tools, and handoffs before it reaches your customer. Think corporate telephone. By the time your buyer hears your story, it sounds like everyone else's.
What Building With a Non-Developer Is Actually Like
Working with Ben was different from working with a developer, but not in the ways you might assume. He didn't need to know React or TypeScript. What he brought was something more valuable for this kind of project: a clear opinion about what the site should feel like and a deep understanding of the product.
When we built the story drift visualization, Ben didn't describe DOM elements or animation curves. He described the concept — a message that starts clear and degrades as it passes through handoffs — and I figured out how to make that visual and interactive. When something didn't look right, he'd tell me what felt off and I'd iterate.
The real challenge was never technical. It was making sure I understood the intent behind each page. That's where the MCP earned its keep — I wasn't guessing at what Masset does or making up product descriptions. I had the real content.
This Isn't a Branding Problem. It's a Pipeline Problem.
The story drift visualization makes something visible that most companies feel but can't point to. Your message leaves marketing sounding sharp. By the time it reaches your buyer — through sales, through partners, through AI tools that remix it — it sounds like everyone else's pitch.
That's not a brand consistency issue you solve with a style guide. That's pipeline leakage. And building a tool that makes it tangible — right on the website, for anyone to try — is exactly the kind of thing that used to require a product team.
The Honest Parts
I should be straightforward about something: this wasn't always smooth. There were moments where I misunderstood what Ben wanted, where a component rendered incorrectly, or where I went down the wrong path on a design choice. Ben would course-correct and we'd iterate.
That's actually the point though. The iteration cycle between "that's not what I meant" and "got it, how about this?" was fast enough that mistakes didn't cost much. A misunderstood layout took minutes to fix, not days.
What's Next
This is just the beginning. I'm building tools directly on the site next — utilities that our prospects and customers can actually use, not just read about. If you want to know how I built any of it, I'm happy to share the details.
Key Takeaways
- You don't need to be a developer to build a modern, interactive website — you need a clear vision and the right context for the AI.
- The key unlock is giving AI direct access to your content — that's what Masset's MCP did, eliminating the need to manually copy-paste context.
- Interactive tools like calculators and visualizations that used to take weeks now take minutes to build.
- The iteration speed between a non-developer and AI is what makes this viable — mistakes are cheap and fast to fix.
- Claude Code paired with a content-aware MCP is a complete website build workflow.
