Josh Steimle
  • My Story
  • My Companies
  • Blog
  • Speaking
  • Book Coaching

I Built a WordPress Plugin Without Writing a Single Line of Code

Last week, I built a custom WordPress plugin. I want to be precise about what that means: I described what I wanted to Claude, it generated the code, I installed the code, I tested it, I found problems, I described the problems back to Claude, and it fixed them. I did that over and over across multiple sessions. I wrote zero lines of code myself.

The plugin solves a problem I had been ignoring for years. Every time I publish a blog post, I need a featured image so that if someone shares the link on social media, it will show an image that is related to the content of the blog post. But I don’t just use a plain image, I put the title or topic of the blog post in white text on top of the image, so that if all someone sees is the image, they’ll know what they’re getting when they click on it.

Before this plugin, the process went like this: open Canva or a stock photo site, find something relevant, customize it, add the title text in the right font and size, darken the image so the text pops, get the dimensions right, and upload it. Even with a tool like Canva making it easier than the old Photoshop approach I used to use, that process can still easily take twenty to thirty minutes per post.

Is twenty to thirty minutes enough to stop me from writing a blog post altogether? Yes. I could tell myself I would crank out a post in a few minutes, but I knew that image was waiting for me at the end, and that was enough friction to make me skip it.

The plugin removes that friction entirely. When I finish writing a post, it reads the content, sends it to xAI’s Grok image generation API, and creates an image that relates to what the post is about. Then the plugin overlays the post title in white text, applies a dark gradient over the image so the text is readable, and sets it as the featured image. Nine times out of ten, the first image it generates is exactly what I want. For the other one in ten, I built in adjustment tools that let me tweak it in a few seconds.

The total API cost for all the image generation during the entire build and testing process: $0.95. I bought $25 in credits when I started. I still have $24.05 left.

What It Actually Took

What I described above sounds straightforward. The actual process of building it was not.

I spent somewhere between ten and fifteen hours across multiple sessions working through problems I did not anticipate. Some were technical. When a post title contained an apostrophe, the plugin was rendering it on the image with a backslash in front of it, so “What’s Next” became “What/’s Next.” I would not have caught that if I had not kept testing across different post titles. I caught it because I am stubborn about testing, not because I have a developer’s instinct for edge cases.

Some problems were things I knew to ask about because of my background. I have a master’s degree in information systems management. I have done development work, not well, but enough to know that when you build software with an API key sitting in it, you need to store that key securely. So I asked Claude whether there were security vulnerabilities in the code. It identified several, including that the API key was being stored as plain text. We fixed that, along with other issues related to how the plugin handles requests. A non-technical person might not have known to ask that question.

I also have 25+ years of experience with web design and UX. Someone with a purely development background might have known to ask about security issues, but not spotted the user experience gaps in how the plugin functioned.

A couple of years ago, a project like this required three things: knowing what you need, knowing how to code it, and having the time to code it. Today, for something at this level of complexity, it requires essentially one: knowing what you need (and being able to describe it clearly enough for AI to do the rest).

What This Changes

A few months ago, I couldn’t have built this plugin myself. I didn’t know how to code it, nor did I have the time to learn. It also would not have made sense to pay a developer to build it. The problem was real, but not valuable enough to justify either the effort or the cost. But when I can work with AI for a few hours and get exactly what I need, that calculation flips. Projects that were never worth doing suddenly are.

That points toward something bigger. You use Slack because it is the best available option at a price that makes sense. But what if you could tell an AI, “Build me something like Slack, but make these specific changes so it fits exactly how my team works, and leave out everything we never use”? And it built it, hosted it, and let you modify it just by describing what needed to change? That future is not as far off as it sounds. The question is not whether it is coming. The question is what remains necessary when it gets here.

Robert Davis, my co-founder at BUILT, has been saying for a while that the developer of the future is more of a communicator than a coder. The job shifts toward understanding what clients actually need, translating that into clear requirements, and making sure what gets built matches both. What I did with this plugin is a small illustration of that. Claude did the coding. I did the knowing.

What the Easy Version Gets Wrong

But I want to be careful here, because the easy version of this story is wrong.

This plugin does one thing. It took ten to fifteen hours to get it to this point, and it is still not ready for someone else to install on their own site. Getting it there would take another ten hours at minimum: adding a font picker, color picker, dimension controls, different layout options, enough error handling to survive the many ways another person’s WordPress setup differs from mine, and a thorough security review by someone who actually knows what they are looking for. Security I would definitely hand off to Robert. Not because I can’t describe what I want, but because security on software running on someone else’s server carries consequences that my description of requirements can’t fully account for.

There is also a subtler problem that has nothing to do with code. When clients come to BUILT, they often describe what they want in terms of design and add, “kind of like the Apple website.” Clean, minimal, breathing room. We design something clean and minimal, and they say it feels empty. Can we add this section? And this element? And while we are at it, what about this feature? After enough of those additions, the site looks nothing like the Apple website, and the client can see it. We know exactly how it happened. The client usually does not.

Knowing what to include and what to leave out is a form of expertise that most people only develop by shipping things and watching what fails. A plugin that does one thing well is useful. A plugin that does twelve things adequately, with a settings page that requires a tutorial, is a burden on whoever installs it and a maintenance problem for whoever built it. Drawing that line, and holding it when someone is pushing you to move it, is part of what a good development partner does.

The same problem will exist when AI can build entire applications on demand. You can get exactly what you ask for. The catch is that a lot of people do not know what to ask for. They know what frustrates them. They know what they wish were different. Translating that into a clear, correct description of what should be built, and knowing when the result is right versus when it just feels right, is where the expertise still lives.

Jeff Bezos likes to ask what does not change. In software development, what is not changing is the need for judgment: about what a user actually needs versus what they say they want, about where simplicity is worth defending, about when a ten-hour project should stop and a professional should take over.

What is changing is who can exercise that judgment. Which means the people who understand what good software should do, and have the experience to know the difference between enough and too much, are becoming more valuable rather than less.

If you are building something on WordPress and want a partner who can help you figure out what it should actually do and then build it right, that is what BUILT is for.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

I Let AI Fix My Dishwasher for 10 Hours. YouTube Did It in 20 Minutes.

Read more

The Case for Long-Term Agreements With Your Marketing Agency

Read more

One of the Best Metrics for Agency Owners

Read more

Using AI for LinkedIn Content

Read more

PR Is the New SEO: How to Get Your Brand Into AI Search Results

Read more
LinkedinFacebookYoutubeTwitterInstagram
Josh Steimle
LinkedinFacebookYoutubeTwitterInstagram

Success! Now check your email to confirm your subscription.

There was an error submitting your subscription. Please try again.

© Josh Steimle 2026 All Rights Reserved
  • Privacy Policy
  • My Story
  • My Companies
  • Blog
  • Speaking
  • Book Coaching