After 25 years in web development, I was burning out. AI didn't automate my job; it changed what my job actually is.
I still sit at my desk all day talking to my computer. That part hasn't changed.
What's changed is that a year ago, I was copying customer IDs between browser tabs, writing SSH commands from memory, and spending an hour just to diagnose a fifteen-minute fix. Now I say out loud, "What tickets do I have open?" and my computer tells me.
This isn't one of those stories about how AI automated everything, and now I make money while I sleep. I wear a small microphone clipped to my shirt. I talk to Claude Code through SuperWhisper all day long. I'm still doing the work. But the nature of that work, what it actually feels like to sit down and do my job, has completely changed.
I'm 50 years old. I've been building websites since 1994. And for the first time in a decade, I'm actually excited about work again.
The Before: Death by a Thousand Tabs
Here's what running a WordPress support company used to look like.
A ticket comes in. Client says their homepage banner isn't showing up. Simple enough, right?
Except I manage over 200 client websites, and I can't keep the details of 200 different WordPress installations in my head. So now I have to figure out which theme they're using. Is this a database issue, a template issue, or something they misconfigured in the WordPress admin? Is this a five-minute fix or a two-day job?
To answer those questions, I'd have to set up a local development environment if I didn't already have one for that client. That means rsyncing files from production, spinning up a Docker container, copying down the database, importing it, and running search-and-replace commands to swap the production URLs for local ones.
Each of those steps requires remembering (or looking up) the right SSH alias, the right server path, the right container name.
So I'd have several terminal windows open. A browser with the production site. Another browser with my local version. I'd be comparing the two, running grep searches through template files, writing database queries to track down where a particular piece of content lives. And every single website is different: different theme, different plugins, different custom code from whoever built it five years ago.
For clients who opened tickets regularly, this was manageable. I already had their local environment set up. I knew their codebase. I could move fast.
But for clients who only call once or twice a year? It was a whole production just to get oriented. Half an hour to an hour of setup work before I could even start diagnosing the actual problem.
And here's the cruel part: by the time I'd invested all that time figuring out what was wrong, I might as well just fix it myself, even if it should have gone to our DevOps team. Even if it was something our project manager could have handled through the WordPress admin. The sunk cost of all that diagnostic work meant the ticket became mine whether I wanted it or not.
So tickets would pile up. I'd look at the queue and think, "That one's going to be a whole thing," and I'd put it off. Not because I couldn't do it, but because the overhead of getting started felt exhausting.
I've been doing this for 25 years. And I'll be honest: I was burning out. The work hadn't changed in a decade. Sure, APIs got fancier, animations got smoother, but fundamentally, we were solving the same problems the same way. And I was tired.
The Spark: What If Claude Could Just... See It?
I started using Claude Code about six months to a year ago. At first, I used it the way most people do: asking it to look at template files, explain what a function does, and help me debug a query. I was still doing all the setup work myself. Claude was just a smarter Stack Overflow.
Then I started using Docker more systematically for local development, and something clicked.
If Claude could access my terminal, and my terminal could access a Docker container running a WordPress site, then Claude could explore that site. It could run database queries. It could search through files. It could compare the database to the template.
I started asking different questions. Not "what does this code do?" but "is this issue in the database or the template files?" Not "help me write this query" but "find out why this user's subscription isn't showing up."
And Claude could do it. It would poke around, come back with findings, and suggest next steps.
The real spark came when I was debugging a membership issue for a client with a complex Stripe integration. A member was having trouble with her subscription: duplicate charges, confusion about whether she was on a recurring plan or had made one-time payments. The kind of issue that used to take me an hour just to understand.
Here's what that investigation used to look like:
- Read the client's ticket (never worded the way I need it)
- Translate their complaint into technical questions
- Log in to WordPress admin, look up the user
- Find their email, note their user ID
- Open the Stripe dashboard in another tab
- Search for the customer by email
- Find they have two customer records (great)
- Check each one for subscriptions, payment history
- Cross-reference the Stripe customer IDs with what's stored in WordPress user meta
- Take notes on paper because I can't keep all these IDs in my head
- Finally, understand what actually happened
- Then start thinking about how to fix it
Now here's what I did instead: I asked Claude to look up the user in the WordPress database, grab all their subscription-related meta fields, then check Stripe for any customers with that email address.
Within minutes, Claude came back with a complete timeline: checkout sessions, which customer ID was used for each, when the subscription was created, when a duplicate customer appeared, and why.
The bug turned out to be in our custom code. When a user clicked "Enable Automatic Renewal," we were passing their email to Stripe but not their existing customer ID. So Stripe created a new customer every time. Claude found the bug, proposed a fix, and I deployed it that same session.
That's when it hit me: I don't need AI to do my job. I need AI to see what I see, and remember what I can't.
Building the System: Teaching Claude My Business
The Stripe debugging moment showed me what was possible. But it was still ad hoc. I'd have to explain the situation to Claude each time, point it to the right files, remind it which server the site was on.
I wanted something more systematic. I wanted to say "let's work on AVSAB" and have Claude already know where those files live, what the Docker container is called, which SSH alias to use, and what weird quirks that particular site has.
So I started building that system. And here's the thing: I built it with Claude.
I'd describe what I wanted out loud (remember, I'm talking to my computer all day through SuperWhisper). "I think we should have a file that defines all our clients and their websites. And you know what, all that information is already in our CRM. So maybe you can pull from there and keep a local copy. And each site should have a dev notes file that tells us the container name, the server, the SSH alias..."
Claude would take that rambling brainstorm and turn it into actual architecture. A sites.yaml file with every operational detail. Dev notes files for each site. Command templates that Claude could fill in with the right values.
We'd work with it for a day, hit friction points, and refine. All through conversation.
The breakthrough was our CRM. Last year, I built our own system, called DogHouse, to replace Zendesk. At the time, I just wanted something that better fit our workflow. But now I realized: because I control the CRM, I can write any API endpoint I can imagine.
So I built an endpoint that lets Claude fetch my open tickets. Another one that lets Claude read the full details of a specific ticket. Another one that lets Claude post a response back to the ticket. Another one for logging time.
Every time I thought, "It would be cool if Claude could just look this up instead of me copy-pasting it," I'd build the API endpoint. And every time I built one, the system got a little more powerful.
The Tech Stack (For the Nerds)
If you're curious about replicating something like this, here's what's under the hood.
Claude Code is the AI. It's Anthropic's coding agent that can execute commands, read files, and interact with external services. It's what I talk to all day.
SuperWhisper handles voice input. I wear a small microphone clipped to my shirt (the battery lasts all day), and I literally speak my commands and questions. It's not dictation-to-text that I then send; it's fluid conversation.
Docker runs local WordPress environments. Every client site has a corresponding container. When I need to test something, I spin up the container, sync the database from production, and I have an exact replica running on my machine.
DogHouse is our custom CRM. It tracks tickets, clients, projects, and time. Because we built it, I can add API endpoints whenever I need them. Claude can read tickets, write responses, update statuses, and log billable hours, all through the API.
MCP Servers (Model Context Protocol) let Claude connect to external services. The big one is Stripe. Claude can query customer records, check subscription status, and review payment history, all without me having to open the Stripe dashboard or copy-paste customer IDs.
YAML configuration files tell Claude about our infrastructure. All client sites are listed with their server locations, SSH aliases, Docker container names, database credentials, and production paths. When I say "work on avsab.org," Claude looks it up and knows exactly how to connect.
CLAUDE.md is a 23KB instruction file that teaches Claude how to work with all of this. It maps trigger phrases to actions: "what tickets do I have?" calls the CRM API; "sync my local" runs the rsync and database import commands; "deploy to production" pushes files and clears caches. It's essentially the operating manual for how Claude should behave in our environment.
The key insight: none of this is magic. It's just APIs and configuration files. What makes it powerful is that Claude can use all of it together, in context, while maintaining a conversation about what we're trying to accomplish.
The Workflow Now: A Conversation, Not a Checklist
Here's what my morning looks like now.
I sit down, clip on my microphone, and say: "What tickets do I have open?"
Claude calls our CRM API and returns a list. Three tickets. One high-priority member payment issue, two medium-priority.
"Let's work on the payment issue."
Claude fetches the full ticket: the original complaint, the conversation history, and which client it's for. It maps the client to a site configuration and tells me, "This is for AVSAB. Their site is on cw-mia2. Want me to read the dev notes?"
"Yeah, and let's look at the ticket details."
Claude shows me the member's complaint, already translated into the technical questions I need to answer. Then it asks: "Want me to sync the local environment and investigate, or should we look at production directly?"
If it seems like a quick lookup, I'll say, "Just check production." If it might need code changes, I'll say, "Sync everything first."
Then Claude investigates. It queries the WordPress database, checks Stripe through the MCP server, and cross-references the data. It returns findings: here's what's in WordPress, here's what's in Stripe, here's where they don't match, and here's what probably caused it.
And then the triage happens. Claude will say something like:
"This looks like a quick template fix. I can make the change and deploy it."
Or: "This is a Gravity Forms configuration issue, no programming needed. I recommend writing instructions for the project manager."
Or: "This is complex. It touches the payment integration and the membership sync. I'd suggest packaging this for DevOps with a detailed plan."
That triage used to take me half an hour to an hour, just figuring out who should handle a ticket. Now it happens in minutes, because Claude can actually look at the issue instead of me having to investigate manually.
When tickets go to DevOps, we include a note: "AI wrote this plan. If you have a better approach, use it." Because Claude is good, but it's not infallible. The DevOps team has context and expertise that Claude doesn't.
When tickets return to our project manager with instructions, Claude writes them. Clear, step-by-step, with screenshots if needed. The PM doesn't need to understand the technical investigation. They just need to know what buttons to click in WordPress.
When tickets are quick fixes, Claude makes the changes, I review them, and we deploy. "Deploy to production" triggers an rsync to the right server, followed by cache clears via the Cloudways API. Done.
Then: "Log this to DogHouse and assign to Ritz."
Claude shows me a draft of the ticket response. I say "looks good" or make tweaks. It posts the update, changes the ticket status, assigns it to our project manager, and logs the time.
The whole flow, from "what should I work on?" to "done, ticket closed," happens in a continuous conversation.
I never lose context. I never have to remember which server the site was on. I never have to copy and paste a customer ID between tabs.
What Actually Changed
I don't have hard metrics. I haven't been measuring tickets per hour before and after. But here's what I can tell you:
Tickets that used to receive a "we'll look into it" response within two hours now get actual solutions within one hour. Not because I'm working faster, but because I'm not burning half my time on setup and orientation.
And honestly? The metrics aren't the point.
The point is that my job changed. I used to spend my days solving clients' problems. Now I spend my days building processes that solve clients' problems.
That might sound like corporate buzzword nonsense, but it's the actual truth.
Instead of thinking "how do I fix this membership bug," I'm thinking "how do I make it so Claude can diagnose membership bugs without my help?" Instead of doing the work, I'm building the system that does the work.
For a small business owner, that shift is everything.
Anyone who runs a small business knows the hardest part isn't doing the job you set out to do. It's running the actual business. Marketing, sales, strategy, process improvement. That stuff always gets squeezed out by client work, because client work is urgent and everything else can wait.
Now I have time for everything else.
I'm writing blog posts (like this one). I'm thinking about new service offerings. I'm improving the system itself because every time I notice friction, I can build an API endpoint or a new command template to smooth it out.
And yeah, I'm 50 years old and kind of tired. This might not just let me do more; it might let me do less. Work fewer hours. Have a life. That's not nothing.
This Isn't Automation. It's Partnership.
Let me be clear about what this isn't.
This isn't "I set up some AI tools, and now my business runs itself."
I still work all day. I still sit at my desk. I still have to understand the problems, make decisions, review Claude's work, and handle the situations that don't fit neatly into the system.
It's not magic. It's not even particularly futuristic, if you look under the hood. It's APIs. Configuration files. A well-documented workflow. Claude is powerful, but its power comes from having access to the right information in the right format.
A year ago, I couldn't have built this. Not because the AI wasn't capable (Claude Code was already pretty good), but because building all the infrastructure would have taken months. Writing every API endpoint, designing every configuration schema, documenting every workflow. The overhead would have killed the project before it started.
The difference now is that I can describe what I want and build it in the same conversation. I can brainstorm out loud, and Claude turns the brainstorm into working code. I can hit a friction point in the morning and have a solution deployed by afternoon.
That's the unsexy revolution. Not "AI does everything now." Just: the cost of building custom tools dropped so dramatically that building custom tools became practical. And once you can build tools for your specific workflow, the leverage is enormous.
I taught Claude to see my business. Then we rebuilt it together, one conversation at a time.
The tickets keep coming in. The clients still have problems. But I'm not dreading the work anymore. I'm not letting tickets sit because the setup feels exhausting.
I'm excited. For the first time in years, I'm actually excited about this job.
And that might be the most valuable thing AI has given me.
The takeaway: The cost of building custom tools dropped so dramatically that building custom tools became practical. And once you can build tools for your specific workflow, the leverage is enormous.
Shane Larrabee is the founder of FatLab Web Support, a WordPress hosting and support company managing 200+ client websites since 2011.