Why this case study is different

Every other case study on this site is hands-on engineering I did at Army & Outdoors or for my own store BrandSHD ? systems I architected and built. This one is different, and I'm telling you upfront: I didn't hand-code this. I directed AI tooling to build it, and I'm being honest about that because it's the most useful thing I can show you about how I actually work in 2026.

The need

I was building ClickBrown ? this website ? on WordPress. Two problems:

  • Updating the theme manually was tedious. Lots of small changes, constantly. Every tweak meant logging in, navigating menus, editing, saving, checking.
  • Building the whole site from scratch by hand would have taken weeks I didn't have, on top of a full-time job and a newborn.

I wanted Claude to be able to manage the WordPress site directly ? create pages, update the theme, manage content ? conversationally. That's exactly what the Model Context Protocol (MCP) enables. The question was how to get there fast.

What I actually did

Instead of spending weeks hand-writing an MCP server, I treated Claude as the builder and myself as the person who knows what needs to exist and whether it's working:

  1. I described the goal ? "I want Claude to be able to manage my WordPress site." Claude proposed building a custom MCP server in PHP and walked me through the approach.
  2. Claude built the tool. The MCP server itself ? the code, the tool definitions, the WordPress integration ? was generated by Claude.
  3. I tested and reported back. Bugs appeared (they always do). I'd hit an error, describe what happened, and Claude would diagnose and fix it. Iterative, collaborative debugging.
  4. Claude gave me the connection instructions. Server-side config, authentication, how to wire the MCP into Claude. I followed them step by step.
  5. It connected. Once live, Claude could operate the WordPress site directly ? and a large part of this very site was then built through that connection, conversationally.

You're reading a site that was substantially built by an AI through a tool that the same AI built, with me directing, testing, and validating every step.

Why I'm showing you this instead of hiding it

Plenty of consultants would dress this up as "I engineered a protocol-level MCP integration from scratch." That would be a lie, and you'd find out eventually.

Here's the honest version, and why it's actually the point:

  • I know what to build. The value wasn't in typing the code. It was in identifying that an MCP server was the right solution, scoping what it needed to do, and recognising when it was working correctly versus subtly broken.
  • I direct tooling effectively. Getting useful output from AI on a real production task ? not a toy demo ? is a skill. Knowing when the output is wrong, how to describe a bug so it gets fixed, when to push back: that's the actual work now.
  • I ship. The MCP server exists, it's connected, it works, and it built a real site. A week of directed AI work versus a month of hand-coding. Same outcome, fraction of the time and cost.

Why this matters for your store

If you hire me, you're not paying for artisanal hand-typed code as a point of pride. You're paying for the right thing to get built, correctly, fast, at a sensible cost. Where modern AI tooling makes that faster and cheaper, I use it ? and I pass that efficiency to you rather than padding hours.

Where the work genuinely needs deep hands-on engineering ? the multi-store sync, the webhook reliability patterns, the customs-label sanitisation, the years-stable production systems in my other case studies ? that's hands-on work I've done and own. Different problems need different approaches. Knowing which is which, and being honest about it, is what you're actually hiring.

That honesty is the pitch. If a consultant won't tell you straight how something was built, ask yourself what else they're rounding up.