Build vs Buy: Why I Wrote My Own WordPress Theme and Plugin

For most businesses, buying a WordPress plugin is the right call. Someone else maintains it, fixes security issues, and keeps up with WordPress releases. I bought one too, a commercial plugin for product boxes and comparison lists, and it served my first seven sites well.

Then I wanted an eighth, ninth, and tenth site, and planned more. The license covered 10 sites. That was the moment to decide: keep paying and stay inside the ceiling, or build my own.

The decision framework

I asked four questions. If you are facing a similar choice, they transfer well.

1. How much of the plugin do I actually use? I audited the settings and content on all seven sites. They used two shortcodes, one for product lists and one for inline links, plus the product table behind them. The plugin had many more features. I used a small slice.

2. Is the core logic tied to my business? Yes. Product data, scores, and how lists render are central to my sites. Owning that code means I can change it the day I need to.

3. Can I keep compatibility? If the new plugin reads the same database table and supports the same shortcodes, existing content works without edits, and my publishing scripts do not change.

4. Can I maintain it? With Claude Code as an engineering partner and a test site to break things on, yes.

All four pointed to building. One option was off the table from the start: modifying or bypassing the commercial plugin’s license check. Its code is proprietary. The honest path was a clean-room plugin that is compatible at the data level and written from scratch.

What AffShelf does

The result is AffShelf, a plugin plus a parent theme and a child theme starter.

The plugin:

• reads and writes the same product table, so old content keeps working
• supports the same list, link, and box shortcodes
• fetches product details through my own crawling service
• outputs ItemList structured data for product lists
• handles outbound links through a clean /go/ redirect
• refreshes product data on a schedule without overwriting editorial fields
• ships WP-CLI commands (add, fetch, refresh, list, settings, import) so a pipeline can publish articles without touching the admin screen

The theme adds what I previously patched in with small must-use plugins: FAQ schema, table of contents, breadcrumbs, a guides hub organized by category, and a sidebar with top picks and a sticky table of contents.

A new site is now one command: create the WordPress install, activate the plugin and themes, configure defaults, connect the data token, and check HTTPS.

The security pass found real bugs

Before installing it on a live site, I ran a second review focused on security and permissions. It found things I am glad were not live yet:

• An open redirect. The /go/?url= handler would redirect to any URL. That is a gift to phishing. It now only redirects to known product links.
• Username leaks. WordPress exposes author usernames through ?author=1 and the REST users endpoint. The plugin now closes both.
• Permissions too narrow. Editors could not manage products, which would have pushed people toward using admin accounts for daily work.
• Empty cards when a product had not been fetched yet, and stale links when posts were deleted.
• Cache-busting. A fixed CSS version meant browsers and the CDN kept serving old styles after an update.

None of these are exotic. They are exactly the class of issue that slips into custom code, which is why a dedicated review pass matters more than the first draft.

What I underestimated

Data overwrite rules. The scheduled refresh updated product titles and images from fresh data, which quietly replaced hand-edited titles. The fix was a clear split: scraped fields can be refreshed, while fields with a custom_ prefix are never touched by automation.

SEO plugin quirks. On a fresh install, the SEO plugin I use did not load its modules until a registration step was marked as skipped. Its sitemap returned 404. The site setup script now sets that option explicitly and flushes rewrite rules.

Links to pages that do not exist yet. A brand-new site has no “About” or “How we test” page on day one. The theme now hides links to pages that have not been published, so an audit on launch day does not report broken links.

Was it worth it?

The newest sites in my portfolio run on AffShelf. The older seven still run the commercial plugin, which is fine. It works, and migration has no urgent payoff.

What I gained:

• no ceiling on the number of sites
• a plugin that does exactly what my pipeline needs
• WP-CLI publishing as a first-class feature
• the ability to fix a bug the day I find it

What it costs: I am the maintainer. Every WordPress update is my responsibility to test.

When you should buy instead

Buy when the plugin is far from your core business, when you would use most of its features, or when you cannot commit to maintaining code for years. Payment gateways, backups, and security firewalls are good examples where a mature commercial product almost always wins.

Build when the plugin sits at the center of how your business works, when you only use a narrow slice, and when owning it unlocks growth that the license would block. For me, AffShelf checked all three.