Someone has to be watching the store after launch

Software rot on a live store is undramatic. WordPress and WooCommerce ship security and feature releases on their own schedule; extensions follow at their own pace, and some quietly stop following at all. Your host upgrades PHP and a plugin written for the previous version starts throwing fatal errors on one template. A payment provider announces an API sunset with six months of notice, in an email to an address nobody reads any more. Meanwhile marketing adds a chat widget, a heatmap script and two remarketing tags, each defensible alone, collectively pushing mobile interaction past the point where shoppers wait. Every one of these is survivable if somebody notices in the same week. The damage comes from the months when nobody does, and from the fact that revenue does not drop in a way that looks like a technical fault.

• Core, plugin and theme releases arriving on four different schedules
• Host-side PHP and database upgrades that break older extensions
• Payment, shipping and tax APIs deprecating versions on their own timeline
• Marketing scripts accumulating until mobile pages respond slowly

Most stores have backups. Far fewer have a backup that anybody has ever restored. An untested backup is a belief rather than a recovery plan, and the moment you discover it excluded the uploads directory, or captured the database mid-write, is the worst possible moment to discover it. Real backup hygiene means knowing where the copies live, that they sit somewhere other than the server they are protecting, how far back retention actually goes, and roughly how long a full restore takes on your host. It also means rehearsal: pull a recent backup into a staging environment, bring it up, place a test order, confirm the order lands. That drill costs an hour and converts an assumption into a number you can quote to yourself at 2am when something has gone badly wrong.

The dangerous update is rarely the one you were worried about. It is the minor release of a plugin that quietly changes a template hook, and now the variation selector has vanished on mobile. So updates run first on a staging copy carrying the real catalogue and the real plugin set, and a human walks the money path by hand: category, product, add to cart, checkout, order confirmation, email. Then they go to production in batches small enough that a break is attributable to one change, at an hour when rolling back is inconvenient rather than catastrophic. A store nobody has touched in two years needs the opposite of a mass update. It needs an audit, a plugin inventory showing what is abandoned or duplicated, and a staged sequence over weeks. Updating forty plugins at once in production is how a two-year gap becomes a two-day outage.

• Staging with the real catalogue and plugin set, not a blank install
• Walk the money path by hand before anything reaches production
• Small batches, so a failure can be traced to one change
• A snapshot taken before every update and a known restore path

Uptime monitoring that pings the homepage tells you the server is on. It does not tell you the gateway is erroring at the final step, or that a shipping plugin update made the place-order button do nothing on iOS. Those failures serve a perfectly healthy response code while revenue quietly goes to zero, and they can persist for days because nothing looks broken from the outside. Useful monitoring exercises the path a customer takes, verifies that key pages return real content rather than a cached error page, and tracks the things that expire on a calendar rather than on demand: certificates, domains, API credentials. It also watches speed, because a regression on the templates that carry revenue is worth catching in the week it happens rather than in next quarter's performance report.

• Cart and checkout checked as a flow, not just a homepage status code
• Certificate, domain and API credential expiry tracked before they lapse
• Speed measured on category and product templates over time
• Analytics and conversion tracking verified so the numbers stay trustworthy

Most WordPress compromises are boring. An abandoned plugin with a published vulnerability, a reused administrator password, an old account belonging to a contractor who left two years ago. Hardening is correspondingly boring: least-privilege accounts, two-factor on admin logins, removing code nobody uses, keeping the attack surface small, and knowing which extensions have stopped receiving security fixes. The part most plans skip is the response. If malware lands, sequence matters — take a forensic copy before cleaning, find the entry point instead of deleting the visible payload, restore from a backup known to predate the intrusion, then rotate every credential the intruder could plausibly have read. Cleaning the symptom without closing the door usually means being reinfected within a fortnight, and by then the store may also be flagged in search results.

Maintenance does not mean handing over the business. WordPress and WooCommerce remain the system of record: products, stock, orders, coupons, customer accounts, tax and shipping rules, and the payment plugins keep running exactly where your team already manages them, with the same logins and the same daily workflow. What a plan adds is custody around that system — the update process, the backups, the monitoring, the security posture and the performance watch. If the customer-facing layer has been rebuilt as a Next.js storefront, the boundary stays clean: WooCommerce owns commerce logic, the storefront owns rendering and speed, and both carry dependencies that move without asking permission. Nothing about how you add a product changes. What changes is that somebody is accountable when something underneath it shifts.

Support means keeping what exists working: something broke, something behaves oddly, a setting needs adjusting, a plugin conflict needs diagnosing. New work is anything that adds capability — a new template, a subscriptions integration, a redesign — and it should be quoted separately rather than absorbed invisibly into a monthly fee. Be wary of any arrangement that blurs the two, because the blur tends to resolve against whoever is paying. Response expectations should be written down and honest for a small senior team: store-down or checkout-down gets attention the same business day, everything else within a couple of business days. Ownership should never be ambiguous either. You hold the hosting, domain, repository and administrator accounts, we work through delegated access you can revoke, and backups live somewhere you can reach without asking anyone. Scope and rates are agreed in writing first.

A maintenance plan is not a substitute for hosting that can carry your traffic. If the store falls over during every campaign, update discipline will not fix it and the money belongs in infrastructure first. Nor is a pla useful if you already have a competent in-house developer running staged updates and testing restores; at that point you are buying a second opinion, not a missing function, and you should buy it as an occasional review instead. Be especially careful at the cheap end of the market. A plan priced at pocket change per month is an automated updater and a dashboard, which means nobody is really watching — the alert goes to a queue rather than to a person who will act on it. That is arguably worse than having no plan, because it feels covered. If you are not sure which situation you are in, ask for a look at the current setup before committing to anything monthly.