People sometimes expect me to start a new WooCommerce job by opening the code and fixing the thing they asked about. I don’t. The first hour goes on something much less exciting: making sure I can’t make anything worse.
It isn’t padding. Every problem I’ve had on a new job that turned into a bad day started with skipping one of these steps. So here’s what that first hour actually looks like, in roughly the order I do it.
1. Getting in safely
Before anything else, I need access, and I need it done properly.
I ask for my own WordPress administrator account in my name, not the owner’s login sent over email. If something changes on the site, the activity shows my name, and when the job’s done you can delete my account without changing your own password. The same goes for hosting: most hosts let you add a second user or a developer login, and that’s far better than sharing the main account.
If a password arrives in a plain email or a WhatsApp message, I’ll use it, then ask for it to be changed once I’m finished. I wrote about the wider mess of missing logins in The Handover That Came With Zero Logins.
In that first hour I also check who else has admin access. It’s common to find three or four old administrator accounts belonging to previous developers, agencies or staff who left years ago. I don’t delete them without asking, but I note them down.
2. Taking a backup I’ve seen with my own eyes
Hosting companies usually say they back up every night. I believe them, but I still take my own backup before I touch anything: files and database, downloaded somewhere that isn’t the same server.
The point isn’t that the host’s backup won’t exist. It’s that I want to know exactly what I’d restore and how long it would take, before I need to. A backup you’ve never looked at is a hope, not a plan.
On a busy shop I also note the time of the backup and the latest order number. If I ever have to roll back, I know exactly which orders came in after it and would need checking.
3. Writing down what’s actually there
Next I make a quick inventory of the site as it is today:
- the WordPress and WooCommerce versions
- the PHP version, and whether the host is offering a newer one
- the theme, and whether it’s a child theme or edits made straight into the parent theme
- every active plugin, and the inactive ones still sitting there
- which payment gateways and shipping methods are switched on
- any custom code, usually in functions.php or a snippets plugin
Most of this is under WooCommerce > Status, which gives a System Status report you can copy in one go. I save a copy with the date on it. That report answers half the questions I’d otherwise have to ask the owner, and it’s the “before” picture if anyone later asks what changed.
This is also where the surprises show up. An old PHP version, a plugin that hasn’t been updated in three years, two plugins doing the same job. I don’t fix any of it yet. I just write it down.
4. Finding or making a staging copy
I don’t do real work on a live shop if I can avoid it. So I look for a staging site. Many hosts include one, and plenty of shops have one that’s never been used, which I covered in The Staging Site Nobody Ever Uses.
If there’s a staging copy, I check how old it is. A staging site from last year isn’t a copy of your shop any more. If there isn’t one, I set one up or ask the host to.
On staging I make sure emails can’t go out to real customers and payment gateways are in test or sandbox mode. Nobody wants a real customer getting an order email for a test I placed.
5. Reading the error logs
This is the part people least expect, and it’s often the most useful ten minutes of the hour.
I look at WooCommerce > Status > Logs, and at the PHP error log on the hosting if I can get to it. I’m not trying to fix everything in there. Most shops have a background hum of notices and warnings that don’t matter much. What I’m looking for is anything repeating, anything fatal, and anything that mentions the problem I’ve been asked to fix.
More than once, the logs have explained the problem before I’d opened a single file. A payment gateway failing quietly, a scheduled task that hasn’t run in weeks, a plugin throwing an error on every checkout. That’s good news. It means the quote I give is based on what’s really happening, not a guess.
6. Placing a test order
Then I go through the shop as a customer. Add something to the basket, apply a coupon if they use them, choose shipping, and get to the payment step, on staging with test payments switched on.
I’m watching for anything odd: slow pages, a shipping price that looks wrong, a field that doesn’t save, an email that doesn’t arrive. I’m also learning how the shop works, because I can’t fix a checkout properly if I don’t know what normal looks like for this particular shop.
If the owner says “it only goes wrong sometimes”, this is where I try to make it go wrong on purpose.
7. Writing notes as I go
Everything above goes into a plain notes file with the date: what I found, what I didn’t touch, what looks risky, and questions for the owner. It doesn’t need to be pretty.
Those notes matter for three reasons. They help me explain what I’ve found in plain English. They protect the owner if I’m ever not around, because the next developer has a starting point, which I talked about in Handing a Site Back to the Next Developer. And they protect both of us if something unrelated breaks next week, because we know what the site looked like before I started.
8. Confirming the job and the fixed price before I change anything
Only after all that do I go back to the owner. I explain what I found, what I think the real problem is, and what I’d do about it. Then we agree the scope and a fixed price for the job before any work starts.
Sometimes the first hour changes the job. The “small checkout tweak” turns out to be a plugin conflict, or the thing they asked for turns out to be a five-minute settings change. Either way, it’s better for the owner to know that before agreeing anything, not halfway through. I’d rather tell you the job is smaller than you thought than charge you for the bigger one.
That’s also why I prefer a quick call before a quote. Ten minutes talking often saves an hour of emails.
Why I don’t skip any of it
None of this is clever. It’s the WooCommerce equivalent of a builder checking where the pipes are before drilling into a wall. But it’s the difference between a job that goes smoothly and one where I’m restoring a backup at 10pm while orders are coming in.
If you’ve got a WooCommerce job you keep meaning to sort out, and you’d like it done this way, book a quick call and tell me what’s going on. You can also read more about how I work as a WooCommerce developer.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece. He did not write these words. Augmented publishing by Neil Matthews.