What I Actually Use Claude Code For (Beyond Writing Code)

Most people think of Claude Code as an autocomplete that grew up. You point it at a repo, it writes code, you review the diff. That's real, and it's most of what the demos show.

But over the last few months it quietly became something else for me: the layer I run my whole operation through. I'm a solo founder. I don't have an ops person, a marketing hire, or a growth team. I have Claude Code, a pile of MCP servers, and a terminal. This is a first-person account of what that actually looks like on a normal week, including the parts that broke, because the broken parts are the most useful thing to read about.

A quick definition so the rest makes sense: MCP (Model Context Protocol) is how Claude Code talks to outside services. You connect an MCP server for, say, Meta Ads or Stripe or your calendar, and from then on Claude can read and act on that service directly inside a session. No glue scripts, no switching tabs. You describe what you want; it makes the API calls.

Here's what that bought me.

1. Launching ad campaigns in plain English

I run Meta ads for my products. I used to do this by hand in Ads Manager, which is a maze of nested menus designed by people who hate you. Now I describe the campaign to Claude Code and it builds it through the Meta Ads MCP.

A real one from this month: "Create a paused conversion-optimized campaign for the July webinar. One ad set, automatic placements, optimize for the Lead pixel event, $20/day, US plus Canada, UK, Australia. Three ads from the creatives in /public/ads, 4:5, 9:16, and 1:1." It created the campaign, the ad set, and all three ads, in about a minute, paused so I could review before spending a cent.

The honest part: the first version was wrong, and not in a way I'd have caught without knowing the platform. Meta's API defaults a new ad set's location targeting to "people living in this location," when what you almost always want is "living in or recently in." Claude built it with the default. I caught it, we fixed it, and then I had Claude write the rule into my project's instructions file so it never makes that mistake again. That last step is the real unlock. The tool doesn't just do the task, it accumulates the judgment, so next time it's right by default.

That's the pattern across everything below: it's fast, it's occasionally wrong in expert-specific ways, and the fix is to encode the correction once so it compounds.

2. Scheduling a cohort's worth of Zoom meetings, then wiring the links everywhere

I run live cohorts. Each one is a two-day event, which means a recurring Zoom meeting, and the join link has to reach every person who enrolls. For a while I did this by hand and, predictably, a few people slipped through and never got their link. Bad.

There isn't a great off-the-shelf MCP for creating Zoom meetings (the hosted ones are mostly read-only, for search and recordings). So instead I set up a Zoom Server-to-Server OAuth app, gave Claude the credentials, and had it create the meetings directly against the Zoom REST API: six cohorts, each a recurring two-day meeting at the same time, cloud recording on, waiting room on, registration off.

Then the part that actually mattered: I had it wire the join links into the codebase so the confirmation email and calendar invite include the right Zoom link automatically, forever. New enrollee buys a seat, the webhook fires, they get a branded confirmation with their join link and a calendar file attached. The manual step that was dropping people is just gone now.

The thing I want to flag here is that this wasn't "Claude wrote a script." It was a conversation that moved fluidly between an external API (create the meetings), a CRM (pull the existing enrollees from Notion), an email service (send each their link individually), and the app's own source code (make it permanent). Stitching those four systems together by hand is an afternoon. It was a few minutes of describing the outcome.

3. The SEO emergency (this is the one that earned its keep)

One morning I checked Google Search Console and the homepage said: "Excluded by 'noindex' tag." For a site that depends on organic and AI-search traffic, that's a five-alarm fire. It means Google is being explicitly told not to index the page.

My instinct was to panic and start rewriting things. Instead I asked Claude to diagnose it properly, and the discipline it applied is worth stealing. The first move was not to trust the dashboard. It ran curl -sI against the live homepage to read the actual response headers, and found there was no noindex header at all anymore. The site was fine right now. Search Console was showing a stale verdict from its last crawl days earlier.

Then it traced the root cause through the Vercel deployment API: the noindex had come from a window when the production domain was briefly served by a preview deployment, and hosting platforms automatically add noindex to preview deployments so your half-built staging URLs don't get indexed. That's a feature, not a bug. The config had since corrected itself, and we confirmed every current production deploy was clean.

So the actual fix was small (request a re-crawl, resubmit the sitemap) and the scary part was a false alarm. But I'd never have known that without the "check the origin before you believe the metric" instinct. We then wrote that triage rule into the project docs too, so the next time anyone sees a scary Search Console verdict, the first step is documented: curl the real headers before touching anything.

While we were in there, I had it set up IndexNow, a protocol that pings Bing the moment a page changes so it gets crawled in minutes instead of days. It's a small API route plus a daily scheduled job that reads my sitemap and submits every URL. New blog posts (like this one) now auto-submit to Bing with zero manual steps. That matters more than it used to, because ChatGPT's search runs on Bing's index. Getting indexed fast in Bing is now part of getting cited in AI answers.

4. Inventory logic that can't oversell, read straight from Stripe

My cohorts have twelve seats. I needed them to mark themselves "sold out" and stop selling at twelve, without me babysitting a counter.

The clean version, which Claude built and I pressure-tested: the seat count is read directly from Stripe (the sum of paid checkout quantities tagged to each cohort), so there's no separate number to drift out of sync. Refunds free the seat back up automatically, because the same logic checks Stripe's refund records. And there's a hard server-side guard at checkout that does a fresh count before creating a payment, so even if someone is looking at a cached page, the thirteenth seat can never sell.

I didn't take that on faith. I had it write tests against my live Stripe data, including a deterministic test that a refund frees a real seat, and confirmed the counts matched my CRM exactly before any of it shipped. Which brings me to the only thing that matters about all of this.

The part nobody tells you: you have to verify everything

Claude Code is fast enough that the temptation is to stop reading. Don't. Two real failures from the exact work above:

• It once pushed a commit with a TypeScript error because I didn't make it confirm the build was green first. The deploy would have failed. We caught it and fixed it inside a minute, but a green build is not optional, and I now make it prove that before anything ships.
• An email-sending function silently broke once because an environment variable was set to an empty string instead of being unset, and the fallback only triggered on "unset." Subtle, real, and exactly the kind of thing that passes a glance and fails in production.

Neither of those is an argument against the workflow. They're an argument for the operator's job in the workflow, which is no longer typing. It's directing, spot-checking, and demanding proof. The leverage is enormous, but it's leverage, which means it amplifies bad instructions as readily as good ones. The skill that's worth the most now is knowing what "done and verified" looks like and refusing to accept anything less.

Why I think this is the actual shift

For two years I've used Claude every day, in and outside of work, and the change I keep coming back to isn't that it writes code faster. It's that the boundary between "things I can do" and "things I'd need to hire for" moved. Ad ops, scheduling infrastructure, technical SEO, payment logic: those used to be four different specialists or four different afternoons. Now they're one conversation each, run by one person who knows what good looks like in each domain and can verify it.

You still need the judgment. You need to know that location targeting has a bad default, that a dashboard can lie, that a refund has to free a seat, that an empty string is not the same as undefined. Claude doesn't replace that knowledge. It removes the distance between having the knowledge and acting on it.

That's the thing I try to teach: not how to make Claude write code, but how to operate it across your whole stack and trust the output for the right reasons. The tool is remarkable. The operator is still the point.