Premium WooCommerce plugins are great — until you realize you’re only using 10% of the features, while still loading all the code, dealing with updates, and paying for a license you don’t fully need.
That’s exactly what happened to me. One of my plugins was doing a job I could replicate with a few custom functions. So I decided to ditch it and replace it with my own code — lightweight, specific, and built just for my store.
But I didn’t just jump into coding blindly. I documented the whole process in a 3-part YouTube series, from scoping the replacement, to prompting an AI for help, to testing the final result on a dev store.
In this post, I’ll summarize the approach, share key takeaways from each step, and help you decide when it makes sense to build instead of buy — especially if you’re comfortable writing WooCommerce snippets.
The Task: Replacing a Plugin With Custom Code
The goal of this mini project was simple: replace a WooCommerce plugin I was using with my own code — because I was only using a small fraction of what the plugin offered.
The plugin in question handled “referrals” — tracking them, displaying them in the admin, auto-generating them on order creation, and allowing manual imports. Useful features, but in my case, I only needed about 10% of the functionality. The rest was either irrelevant, unused, or overcomplicated for my store.
Instead of keeping a plugin that loaded unnecessary code and introduced more maintenance work, I wanted to build something that did just what I needed:
- Store referrals in the database
- Display them in the admin
- Allow CSV imports of historical data
- Auto-generate referrals when specific orders come in
That’s it. No extra menus, no settings panels, no marketing banners — just the essentials.
But this wasn’t just about writing code. I wanted to show how to approach this kind of replacement properly: by planning first, structuring your logic, using the right tools (including AI), and testing before going live. That way, you don’t end up with another bloated mess — just lean, understandable, maintainable code.
This blog post (and the 3-video series it’s based on) walks through that whole process — from the idea to the final result.
If you’ve ever wondered when it makes sense to replace a plugin — and how to do it without overengineering — you’re in the right place.
Episode 1: Planning the Replacement
Before writing a single line of code, I needed a plan. In Episode 1, I explain why the plugin I was using no longer made sense for my needs, and how I scoped a simple MVP to define the functionality I actually wanted to rebuild. It’s easy to assume you need to replicate everything a plugin does, but the truth is — if you only used 10% of it, you probably only need to rebuild that 10%.
I also share my process for writing a minimal, no-fluff MVP document. This helps me stay focused and avoid overengineering. The goal is not to recreate a plugin — it’s to build just enough code to do the job better.
If you’ve ever looked at your plugin list and thought, “Surely I don’t need all this,” this video is a good place to start.
Episode 2: Writing the Prompt
Once the MVP was ready, it was time to turn it into code — with a little help. In Episode 2, I take that document and convert it into a proper prompt, structured so an AI can actually understand what I need. But instead of throwing everything into one giant request, I break the functionality into sections and work on one at a time.
I test a few different AI tools to see which one gives me the cleanest, most usable WooCommerce code.
In this episode, I focus on just the first section of the MVP. The remaining parts were completed offline for time reasons, but the process I show here is repeatable and modular — perfect for devs who want control without overwhelm.
If you’ve been curious about using AI to speed up WooCommerce development, this episode walks you through a practical real-world example.
Episode 3: Code Review & Testing
In the final episode, I walk through the full custom code I ended up with — section by section — and explain how it replaces the original plugin. I also show the admin interface, the frontend behavior, and most importantly, run some tests.
These include importing legacy referral data via CSV (since we don’t want to lose history) and creating a test order to check if the referral gets auto-generated as expected. Everything’s designed to be minimal, specific, and functional — no extra fluff.
This episode ties everything together and shows how a few focused functions can fully replace a premium plugin, as long as you’re clear on what you need.
What’s Next?
This might have been a 3-part series, but the story’s not over. After some Twitter feedback, I started questioning whether using a custom post type for referrals was actually the right approach — or if it’s overkill for this use case.
So there might be an Episode 4 coming soon, where I explore switching from CPTs to custom database tables to make things even leaner and more scalable.
Keep an eye on YouTube and make sure to subscribe if you’re curious to see how that plays out.
