A familiar moment now ends differently. A plugin vendor changes the deal (a forced bundle, a steep renewal, a feature moved behind a higher tier), and the replies used to be "which alternative?" Now a growing share say something else: we'll just rebuild it with AI.
Across the communities we follow, we've seen it from many angles. Agencies with one client on an LMS and another on an events calendar say they're considering having an AI assistant write both from scratch. Others are already part way through, moving an events setup to a custom post type with AI help, or swapping a commercial theme for plain block markup and custom CSS. Small nonprofits are generating their own calendar connectors so they don't need a paid add-on. Founders leaving hosted community tools talk about rolling their own. And on the other side, just as many people push back hard. The most common reply is a warning about maintenance, and a close second is that time spent cloning an LMS would be better spent selling the courses on it.
We build and maintain WordPress plugins for a living, so we have a stake here, and we'll say where we lean at the end. First, the camps.
Camp 1: "Most plugins are a custom post type with a UI. Rebuild only what you use."
The argument is simple. Many sites use a small slice of a big plugin: a list of events, a few courses, a booking form. Pay renewals for a whole suite, absorb its updates and conflicts, and you carry weight you never asked for. An AI assistant can generate the slice you need in an afternoon, and the code is yours.
People in this camp often already had a bad run with the original: performance issues, broken updates, a default view that changed under them. For them the rebuild is less about saving money and more about getting control back.
Camp 2: "Writing it is the easy part. Owning it is the job."
This camp doesn't dispute that an assistant can produce a working first version. It disputes what happens in year two. Who patches it when PHP or WordPress moves on? Who handles the edge cases that only show up after launch: recurring events across a daylight-saving change, quiz retakes, refunds, certificates with the wrong name, an RSVP list that has to be exported for a venue?
There's a second point here that gets less attention. Commercial plugins are priced to fund updates and support. Without renewals, software stops getting updated, and the same people who resent the renewal will feel that loss later. Some go further and say plugins have been priced too low for years, and the bundle shocks are the correction.
Camp 3: "Rebuild the thin parts, keep the heavy ones."
Many of the most considered replies landed here. They draw a line by how much state and money a feature carries:
- A calendar display, a styled listing, a theme's layout: fair game to rebuild.
- Anything with payments, enrolment records, progress history, certificates, check-in or compliance: keep a maintained product, even if it changes.
This camp also points out that "start clean" and "fork the old thing" are different decisions. Forking a heavy plugin keeps its baggage. Starting clean with a small custom build or a lighter product drops it.
The grey areas
These are the parts of the debate that never seem to settle:
Who is the maintainer? If an agency rebuilds a client's events system with AI help, the agency now owns a product. Is that in the care plan? At what rate? Does the client know?
Is the code actually understood? An assistant can produce code faster than a team can review it. Several people raised the worry that whoever ships it can't explain it, which matters most when something breaks at 9 pm before an event.
What does the client lose? Docs, a support desk, a changelog, a community of other users who hit the same bug first. None of that comes with a rebuild.
Is it a protest or a plan? Some rebuilds read as a reaction to a price change. That's understandable, but a reaction rarely includes a plan for year two.
Where we lean
Camp 3, mostly. For display-heavy, low-stakes features, a small custom build is often the cleaner choice, and AI help makes it cheaper than it used to be. For anything that holds money, learner records or attendance history, we'd still rather a maintained product carry that weight, whether that's a commercial plugin, an open-source one or a hosted tool. The question we'd ask before any rebuild: if this breaks on the busiest day of the year, who gets the call, and can they fix it without the assistant?
We're curious where you land, because this is moving fast and the answers we see are still mostly opinions, not postmortems.
Your turn
- Have you replaced a paid plugin with something you (or an assistant) wrote? What did year one of maintenance actually look like?
- Where do you draw the line between "rebuild it" and "keep a product": payments, user records, something else?
- If you're an agency, do you bill for maintaining code you generated for a client, and how did you explain that to them?
- When a vendor changes the deal, what makes you stay: support, updates, the ecosystem, or just migration cost?
We read every comment. Stories from people who rebuilt and then went back to a product are especially welcome.
Top comments (0)