I got tired of software that almost did what I wanted. So I stopped. When a commercial tool annoys me now, I sit down with Claude and build my own, and I’ve done it enough times to have strong opinions about what works and what bites you.
Most of it works. Some of it bit me hard.
Think of Claude as a general contractor building a house. You hire the contractor, the contractor brings in the electricians and the plumbers, and when the job’s done it’s still your house with your name on the mailbox. Nobody remembers who poured the foundation unless it was Frank Lloyd Wright. People care that the lights come on. But you’d be a fool to move in without walking through every room first, and I’ve learned that lesson more than once.
Why build your own software tools instead of paying for a subscription?
Because the subscription tool does what the vendor wants, and you want it to do what you want. I spent 33 years in enterprise technology, and companies bend their whole operation around some package built for somebody else all the time.
I hate that.
A small business owner does the same thing on a smaller scale every time they shape their week around a scheduling app’s limits. Why should a monthly subscription decide how your calendar works?
My booking system replaced You Can Book Me, the same job most people hand to Calendly. My goal was everything those tools do plus a few things of my own, and nobody sells that combination.
A small example. The “join here” link on my booking page isn’t a Zoom link. I can change where it goes on my end, so if I want Riverside that week instead of Zoom, I switch it and the guest doesn’t know until they click. That link is one of the reasons I built the thing myself. With an ordinary meeting link, switching rooms means sending everybody a new link and a confused apology.
Security pushed me the rest of the way. I had a few third-party WordPress plugins installed, and the company behind them sold them to a third party. The buyer turned out to be a hacker. An infected update hit something like 600,000 installs before anyone noticed, and my site was one of them. The whole mess is in the anatomy of that supply-chain attack.
After that, every plugin somebody else wrote looked like a door left unlocked for a stranger.
Today the site runs more than 90 custom plugins and only three or four from outside. The outside ones are big security packages from major companies that download fresh threat signatures every day. They’re humongously complicated, and I’m not going to rebuild those. Everything else belongs to me.
Forty-four versions of a booking page
The first working version of my booking plugin took a couple of hours. I described what I wanted, Claude wrote it, and then we went back and forth. Claude, that’s wrong. Claude, this part is wrong too, fix it. That loop is most of the work, and it went on a lot longer than a couple of hours. Getting the whole scheduler to do everything on my list took several days of Claude.
By the day Joe tested it with me, the thing had gone through 44 versions.
Forty-four doesn’t embarrass me. Nobody ships a booking system in one pass, whether a person writes it or Claude does. Software grows by breaking, and each round of fixes closes a hole somebody would have fallen into. The version that broke without telling anybody is another story.
The bug that ate my bookings
The form had been acting up, so I had Claude add a feature that saved what a person typed every few seconds as they went. If somebody got halfway through and quit, I could see where they stopped. It seemed smart. An entry would build up on my screen in real time while a guest filled it in.
Then came a quiet week. No bookings at all.
I figured it was a slow week. My friend Joe Rockey, a business coach I talk with regularly, swore he’d signed up through the form and couldn’t understand why his entry wasn’t there. So he went through it again, live, on a call, while I watched my screen. His answers appeared as he typed. He clicked submit, his screen told him everything was fine, and then his entry vanished from my side. No booking anywhere.
The feature added to catch bugs was the bug. It deleted the saved record as the person went, then tried to create the booking from a record it had already thrown away. The guest saw a happy confirmation. I saw nothing. How many people booked that week and walked away thinking they had a slot with me? I’ll never know.
That one made me furious.
I pasted the problem into Claude and wasn’t polite about it. Who taught you to program? It found the cause in a couple of minutes and started explaining the whole chain line by line, and I told it I didn’t care, just fix the damn thing. It did.
Joe thought being mean to it was a bad habit. Fair enough for people. With Claude, telling it I’m really pissed gets me a slightly better job, and there’s a whole post here on cursing at an AI if you want the longer argument.
A human programmer could have written that same bug, and plenty have. A screen that says “success” proves nothing until somebody checks what came out the other end. Joe found it in a few minutes because he was a real person going through the real form. Whoever builds a form tests it along the path they expect. Real people wander off that path.
Claude is a general contractor. It’s still your house, and you still have to walk through every room before you move in. – Richard LoweShare on X
Can a non-programmer build a WordPress plugin with Claude?
Yes, and the small ones are where it shines. You’ll get more out of it if you can read a little code, but you don’t need to write any.
Every post on my site needs an SEO title, a description and a couple of other fields that Google and the AI search engines read. I always forget to fill them in. So Claude built me a plugin that lists my posts with a little box next to each field, green if it’s filled and red if it’s empty. Click a red box and the plugin calls Claude through the API and writes the missing title or description. It worked the first time, and it took about half an hour to build.
Someday I should automate it so it fixes every empty field on its own. I haven’t. For now I go through the list, find the red ones and fix them.
Another day I didn’t like how comments looked on the site. I told Claude to make me a plugin that changed them, it asked what I wanted, I described it, and a few minutes later it was working. Most of my plugins are like that. Each one does one tiny job, and none of them would ever exist as a product anybody would sell me.
If you’re a writer with a WordPress site, start with the annoyance you feel every week. A missing field, an ugly page, a report you build by hand. Describe it to Claude in plain English, say what should happen and what should never happen, and ask how to install the result.
Keep each plugin small. A plugin that does one thing is easy to test, and when it breaks you know where to look. If your site already looks like a junk drawer, read my notes on putting WordPress on a plugin diet first.
Test it on something you can afford to break
My backups taught me this one, and testing them was a nightmare.
The backup app I’d been using annoyed me, so Claude wrote me a small application that runs on my WordPress site and sends backups straight to Backblaze, a cloud storage company. Backups belong somewhere safe and separate from the site they protect. To test it properly, I built a fake website to back up and restore.
My software had a bug. It restored over my live site instead of the fake one.
So I restored the real site from backup. Strange way to find out your backups work. Claude was very sorry, and sorry doesn’t bring back a website. With no backup to restore from, sorry would have been all there was. My website backup guide says to keep more than one copy in more than one place, and a day like that one shows why.
Before you run anything Claude builds against real data, make a copy of that data somewhere the new tool can’t reach. Point the tool at a test copy first. Read what it’s about to do, and if it deletes, overwrites or sends anything, run it once by hand and watch it. Most of these tools fail by doing nothing. A tool with a delete command fails by doing everything at once.
How do you keep Windows scheduled tasks from failing silently?
You build a second task whose only job is to check on the first ones.
Joe asked me how to get something running continuously in the background on his Windows machine, a job that should happen every day without him touching it. Windows has had a scheduler built in since Windows 95. Claude writes the job in Python, writes a little batch file that runs the Python script, and walks you through setting it up in Task Scheduler. The scheduler is a pain in the ass to use, but Claude will hold your hand through every screen.
A bunch of these run on my machine, doing all kinds of different things. One sends my newsletter: I drop the finished issue into a folder and the script picks it up and sends it out. I also have a little Python menu app holding the chores I kept doing by hand, from downloading YouTube transcripts to encrypting files before they go to my website. Each job goes into the script once, and I never have to remember how to do it again.
Run every task by hand before you schedule it.
Then tell Claude to add some debug logging, enough that when something fails you can go read the error, but not so much that the log eats your whole disk over a few months. A log file that grows forever is a failure with a date on it.
And remember how scheduled tasks fail. Unless you’re doing mass deletes, the worst outcome is a task that doesn’t run and doesn’t tell you. Would you notice a dead job? A job can die on a Tuesday, and you won’t notice until somebody asks a month later why your newsletter stopped coming. Silent failures drive me up the wall. My booking page died of the same disease.
Luckily, the cure is cheap.
Have each task write the date it last ran into its own little text file when it finishes. Then set up one more scheduled task that runs once a day, reads those files and warns you when any job’s date is older than it should be. “XYZ didn’t run.” That one line is worth more than the rest of the system. Claude can put the dates in a small database if you want something sturdier, but a text file per job does fine on one person’s machine.
What can’t Claude build for a small business?
It can’t build anything on a platform designed by people who hate you.
I tried to have Claude write a routine that would post automatically to Facebook. Facebook’s setup for that is so complicated that Claude barfed on it. I’m a designer and I know how these things get built, and I can’t believe a human being designed anything that stupid. Who builds a door that nobody can open?
Google’s tools are better and still a slog. Cloudflare’s are complicated because they do a lot, and things get done there in minutes. Claude came up with the twenty security rules on my Cloudflare account, rules that would have taken me weeks, and I’d have gotten them wrong. Claude got some of them wrong too, and we fixed them together.
Claude also can’t tell you what you need.
It builds what you describe. Describe the wrong thing and you’ll get a very well-built wrong thing. Whose fault is that? A couple of times it’s pushed back and told me I didn’t want to do something, but don’t count on that.
It can’t own the result either. When the booking page lost those signups, nobody at Anthropic lost a guest. I did. Every tool you build is yours to maintain, patch and babysit, and no vendor support line answers at two in the morning. Most of what teams get wrong about software testing applies to a one-person shop exactly the same way.
And it won’t save you from the normal programming cycle. Claude will build the thing in a few minutes. You’ll spend a few hours figuring out why it didn’t work and telling it to fix it, and the next day you’ll run across three or four more bugs. Anybody who has written software knows that rhythm. Claude makes it faster. The rhythm stays.
What a writer can take from all this
If you’re not using AI, you’re making yourself obsolete. Your novel doesn’t have to be written by a machine. But you’d better be using it as a tool for the chores and the plumbing around the writing, because the writers who do will get far more done in a week than the ones who don’t. I wrote a whole book on the subject, The Birth of the Augmented Human.
I gave up ChatGPT more than a year ago, and Claude does all of this work for me now. Pick whichever assistant you like. Your habits count for more than the brand.
So start with one annoyance. Keep each tool doing one job. Test it by hand, on a copy, with a real person going through it if people will use it. Add enough logging to diagnose a failure and no more. Build a watchdog for anything that runs without you watching. When the screen says success, go look at what came out the other end.
My AI and writing hub has the rest of what I’ve learned about putting these tools to work, and if you want help figuring out where AI fits in your own writing or your business, my AI services page explains how I work. Hire the contractor. Let it bring in the crews and carry the lumber. But your name is on the mailbox, so walk every damn room before you hand anybody the key.
