Inside a Care Plan Month: Everything We Did for One Client in 30 Days

One real client, one full month, every task logged. What a WordPress care plan actually does when it is working — and what it quietly prevents.

Ali
4 min read
14+ Years Experience NDA-Protected

Get a Free Quote

Tell us about your project. We respond within 24 hours.

No spam. Your info is protected under NDA.

Hero image with bold headline on the left and a laptop showing a Care Plan Activity Log on a desk.

Key Takeaways

  • Nine hours of logged work in one month — updates tested on staging, a checkout-breaking bug caught before production, a failed order recovered.
  • The update process matters more than the updates: staging clone, money-path testing, screenshot comparison, then production with a fresh backup.
  • A dormant admin account left by a previous agency was found and removed — stale privileged accounts are how most 'we got hacked' stories start.
  • Database cleanup removed abandoned autoloaded options and cut average response time by roughly 180 milliseconds.
  • The real value is the problems you never hear about — every one is cheap to catch early and expensive to discover late.

“What do you actually do all month?”

A client asked us that on a renewal call last year. Fair question. A care plan is a monthly fee for work that mostly happens when you are not looking. If we do the job well, nothing visible happens at all — which makes it look, from the outside, like nothing happened.

So we pulled the log. This post is that log: one real client, one full month, every task listed with the time it took. We have anonymised the client — a UK retailer on WooCommerce, around 4,000 sessions a month, roughly 90 orders a week. Nothing else is changed.

Week one: updates, the careful way

The month opened with 14 pending updates: WordPress core (a minor release), nine plugins, two themes, and WooCommerce itself.

Here is the part most site owners never see. We do not press update on a live store. Ever. The sequence:

  1. Clone production to staging
  2. Run all 14 updates on staging
  3. Click through the money paths: homepage, product page, add to cart, checkout, payment
  4. Compare screenshots of key pages before and after
  5. Only then update production, one batch at a time, with a fresh backup taken first

That week, the process earned its keep. The WooCommerce update changed template markup that the theme’s checkout override had not caught up with. On staging, the order summary rendered without line-item totals. On production, that would have been a support-ticket generator at best and abandoned carts at worst. We held that one update back, patched the override, shipped both together three days later.

Time spent: 3 hours 40 minutes. Client-visible events: zero. That is the point.

Week two: the uptime alert at 2:14 a.m.

Our monitoring pinged at 2:14 a.m. on the Tuesday — the site stopped responding. It was back by 2:31 a.m. without intervention. The host had a brief platform issue.

Why mention a 17-minute blip that fixed itself? Because of what happened next. We checked the morning after: error logs, database integrity, whether any orders had failed during the window. One order had died mid-payment — money taken by the gateway, no order recorded in WooCommerce. We reconciled it manually with the gateway dashboard, recreated the order, and emailed the customer before they noticed anything was wrong.

The client found out about all of this from our monthly report. The customer never found out at all.

Time spent: 1 hour 10 minutes, mostly on the reconciliation.

Week two, continued: security scans and the fake admin

Routine malware and file-integrity scans run daily on every plan. Clean all month. The security event that mattered came from somewhere else: our user audit flagged an administrator account created 14 months earlier by a previous agency — generic email, never logged in since creation.

Dormant admin accounts are how “we got hacked” stories start. Independent security research consistently puts access-control failures among the top WordPress attack vectors, and stale privileged accounts are the softest version of that target. We confirmed with the client that nobody recognised the account, exported a record of it, and removed it.

Time spent: 35 minutes.

Week three: the small fixes nobody budgets for

Care plans include a monthly allowance of small tasks. This month the client used it for:

  • A banner for their seasonal promotion — built, scheduled, tested on mobile
  • A contact-form field change (adding a “how did you hear about us” dropdown)
  • Fixing a product image that displayed stretched on Safari only

None of these justify hiring a developer on their own. All of them sat on the client’s to-do list for weeks before they had a care plan, because finding someone to do a 20-minute job costs more effort than the job itself. This is, quietly, the benefit clients end up valuing most — we wrote more about that trade-off in our comparison of retainers versus one-off projects.

Time spent: 2 hours 5 minutes.

Week four: performance drift

Sites get slower on their own. Plugins add weight, databases grow, image libraries swell. Part of the monthly routine is catching the drift before users feel it.

This month’s check found the database’s autoloaded options had grown 40% since we took the site on — a plugin uninstalled long ago had left behind option rows that loaded on every single page view. We cleaned them out and re-measured: average server response time dropped by roughly 180 milliseconds.

No one notices 180 milliseconds. Everyone notices the slow site you get after five years of never doing this.

Time spent: 1 hour 30 minutes, including before/after measurement.

The month in numbers

  • 14 updates tested on staging and applied — one held back and patched before it broke checkout
  • 1 checkout-breaking bug caught before production
  • 1 failed order reconciled and recovered — customer never knew
  • 1 dormant admin account found and removed
  • 3 small fixes shipped from the monthly allowance
  • ~180 ms shaved off average response time
  • 30 daily backups verified restorable — we test-restore monthly, because an untested backup is a hope, not a backup
  • 9 hours of logged work in total

Is a care plan worth it?

Do the maths against the alternative. Nine hours of reactive freelance time at UK market rates costs more than this client’s plan — and reactive time arrives late by definition. The checkout bug alone, live for a weekend, would have cost more in lost orders than the plan costs in a quarter.

But the honest version of the pitch is not about the hours. It is about which problems you never hear about. Updates that break things quietly, orders that vanish between gateway and store, admin accounts nobody remembers creating — every one of these is cheap to catch early and expensive to discover late.

If you are weighing it up, start with our plain-English breakdown of what separates a care plan from basic maintenance, or see exactly what each tier includes on our care plans page. And if you just want to know whether your site has any of the problems described above, our free audit checks for them — dormant admin accounts included.

Share:
FAQ

Frequently Asked Questions

Need Expert WordPress Help?

From custom development to ongoing care plans, we build WordPress sites that work as hard as you do.

Explore Care Plans
Written by

Ali Shan

WordPress developer with 14+ years of experience building custom themes, plugins, and WooCommerce stores. Founder of WPRobo.

Your email address will not be published. Required fields are marked with an asterisk.