Short answer: a store has a launch price and a cost of ownership — and almost nobody warns you about the second one. It is made of plugins, licences, updates, conflicts and the hours spent keeping all of it working. Over time that cost rises while your ability to change anything falls.
How it accumulates
The mechanics are the same nearly everywhere, and each step is reasonable on its own. Need a shipping calculator — install a plugin. Need reviews — another one. Filters, "bestseller" badges, a marketplace feed, a newsletter pop-up, chat, a landing page builder — plugins, plugins, plugins. Each individual decision takes an hour and costs pennies.
Two years later the store runs 40 plugins, a third of which are unused, half of the rest duplicate each other's functionality, and two have been abandoned by their authors. Nobody ever decided "let's make this complicated"; the complexity accumulated by itself, one reasonable step at a time.
What you actually pay with
Speed. Every plugin adds database queries and its own CSS and JS to every page. That is a direct conversion loss.
Security. Plugins are the primary attack vector for WordPress sites. A vulnerability in one popular extension affects hundreds of thousands of sites at once, and attackers scan for them in bulk. For a store the price of a breach isn't only downtime — it's customer data, with all the legal consequences.
The ability to update. A familiar situation: a WooCommerce update breaks compatibility with a plugin, the author is silent, and the store stays on the old version. Then PHP can't be updated, then WordPress, and a year later you have a stack nobody dares touch.
Speed of change. A simple task like "add a field to checkout" turns into an investigation: which of the four checkout plugins owns this, and what breaks. This is exactly the "why does something so small take two days" feeling.
Money directly. Fifteen premium plugins at €60–100 a year is €1,000–1,500 annually just for the right to keep using what you already have.
Six hygiene rules
1. Audit plugins twice a year. For each: is it used? could it be replaced by one function in the theme? has the author shipped an update in the last year? Anything failing gets removed. Not deactivated — removed, along with its tables.
2. Nothing changes directly on production. A staging copy isn't a luxury, it is a precondition. Updating the cart plugin on a live store on Friday evening is betting with your revenue.
3. Backups that have been tested by restoring them. A backup that was never restored is not a backup, it is a hope. Once a quarter, restore it to staging and confirm the store comes up.
4. Updates on a schedule, not in a panic. Once a month: staging → update → check the key flows (order, payment, emails) → production. Boring and predictable, which is exactly right.
5. Minimalism by default. Before installing a plugin, ask: could this be 20 lines in the theme? Often it could, and then it is cheaper to own for years.
6. Document the non-standard parts. One file describing which plugins are critical, what was configured by hand, where the custom code lives. That is what separates a store you can hand to another contractor from a store holding you hostage.
Three exit scenarios when the debt is already large
Scenario 1: clean up. Remove what isn't used, replace one-trick plugins with code, get updates back on track. One to two weeks, removes most of the pain and almost always pays for itself. This is where you start — the other options without this step just relocate the chaos.
Scenario 2: rewrite the templates. Drop the page-builder theme and build the templates you need directly. Harder, but it removes the main source of weight and makes the store predictable. Justified when the design is fine and the speed isn't.
Scenario 3: split storefront and backend. WooCommerce stays as the system of record — products, orders, payments, the admin your team already knows — and the storefront is built separately. Speed stops depending on plugins, and frontend changes stop threatening orders. When this pays off and when it doesn't is covered on the WooCommerce and headless page; a ready-made version of that move is NextWoo.
If the store sits on a platform that has genuinely run its course, that is a separate conversation: website or CMS migration.
Developer note
- Inventory from facts, not memory. A list of plugins plus the author's last update date plus where each is actually used. A plugin with no calls in the templates is a removal candidate.
- Look for residue from deleted plugins. Rows in
wp_optionswithautoload='yes', orphaned meta fields, cron jobs pointing at code that no longer exists. - Separate custom code from the theme. Functionality goes in its own plugin, presentation in the theme. Otherwise an update or a theme switch takes your business logic with it.
- Pin versions and keep environments identical. A PHP version mismatch between staging and production invalidates all your testing.
- Track vulnerabilities automatically. Subscribing to a plugin vulnerability feed is cheaper than hearing about a problem from customers. Security practices are covered in web application security; baseline performance guidance is in the WordPress documentation and the WooCommerce Developer Docs.
- Log errors in production. A store where nobody reads the logs learns about broken payments from a customer — a day later, in a review.
Practical check
- Listed every plugin with the author's last update date
- Removed the unused ones along with their data
- A staging copy exists and changes go through it
- A backup has been restored and verified in the last 3 months
- Updates run on a schedule, not "when something breaks"
- I know the annual licence total
- There is a document describing the customisations
- PHP and WordPress are on supported versions
The consolidated 90-day plan
To close the whole guide, here is the order of work I would propose to almost any store:
Weeks 1–2. Measure. Collect the five funnel numbers, reconcile analytics against the admin, capture Core Web Vitals, read the zero-results search report. Fix nothing yet — just find where it breaks. See funnel diagnostics and analytics.
Weeks 3–5. Checkout. Guest orders, honest shipping cost upfront, fewer fields, a proper mobile form, payment methods. The fastest payback on the list — cart and checkout.
Weeks 6–8. Speed and product pages. Images, caching, cart fragments; on the product page, delivery date, stock, size chart, reviews. See speed and the product page.
Weeks 9–10. Visibility and trust. Filters out of the index, out-of-stock handling, markup, contacts and return terms: SEO mistakes and trust.
Weeks 11–12. The second purchase. Post-purchase sequence, segments, reactivation — retention and LTV.
In the background, throughout. Plugin cleanup, staging, backups, updates.
After 90 days you won't have "a new site". You'll have a store where you know exactly where the money leaks — and where noticeably less of it does.
If you want someone to run this plan for you: conversion optimisation, website speed optimisation or product support and growth, depending on what the first week revealed.