What if the bug turns out bigger than expected?

I tell you as soon as I know, with what I found and the options. Nothing beyond the agreed scope happens without your say-so.

Do you need access to production?

Not at first. I prefer a copy or staging site. If the bug only shows in production, we agree on read-only access or a supervised session.

What if you cannot reproduce it?

Then I say so and ask for more detail, such as the browser, account type, steps and time. Some intermittent bugs need logging added first so the next occurrence can be captured.

Will you tell me exactly what changed?

Yes. You get a short written note and the code change itself.

Fix one bug in your website or web app, scoped and handed back

A single-bug job has a clear shape: agree what “fixed” means, reproduce it, find the real cause, fix it, test it, and hand it back with notes. Keeping it narrow is what keeps it quick and the price fixed before work starts.

How I scope one bug

Before I touch anything I need a sentence that describes the problem and a sentence that describes the correct behaviour. For example: “When a customer applies a discount code at checkout, the total shows the old price. It should show the discounted total.” That sentence becomes the acceptance test at the end.

I ask for:

the steps to trigger it, and how often it happens
the browser, device or account type involved
a screenshot, an error message, or a recording
when it last worked, and what changed around then

Reproduce first

I do not guess at a fix. I reproduce the problem on a copy of the site or app, or with the same data in a local setup. If it only happens for certain records or certain users, I find what those have in common. A bug I can trigger on demand is usually half solved.

Find the cause, not just the symptom

I list a few possible causes and rule them out one at a time, reading the full path from the click to the stored result, not only the line where the error appears. Typical culprits: a plugin or dependency update, a date or timezone assumption, a missing null check, a stale cache, a permission difference between roles, or two systems disagreeing about the same field.

Then I check the neighbours. If one place had the fault, similar code elsewhere might too, and I tell you what I found even when it is out of scope.

Fix, test, hand back

The fix is the smallest change that corrects the cause.
I add a test where the code has a test setup, or a written manual check where it does not, covering the original steps and the edge cases around them.
I re-run the main flows nearby to make sure nothing else moved.
You receive the change, a short note (cause, fix, how I checked it), and instructions to roll back if you want to.

When this is the wrong engagement

If the real issue is that the system has outgrown its design, a bug fix will only buy time. I will say so and suggest options, but I will not turn it into a rebuild without your agreement. If the problem is a hacked WordPress site, a different process applies, see the related post.

What I need from you

The description above and any error messages.
Access to the code or site (staging preferred) and the hosting or deploy method.
One person who can confirm the bug is fixed and reply quickly with questions.