Results — case notes from NZ sites we've fixed

A 4,000-SKU store on shared hosting in Sydney

Category pages went from 8.4 seconds to 1.6 — without a bigger server

The situation: Checkout worked, but category and search pages took eight seconds or more at any traffic. Two hosts had already recommended a larger plan.
What we found: A faceted-filter plugin was running an unindexed query across the full product table on every page render, then discarding most of the result. Server load was a symptom, not the cause.
The decision: Fix the query before touching the hardware. We rewrote the filter to use indexed lookups, added an object cache for the term counts, then migrated to Auckland for the latency win.

8.4s → 1.6sCategory page, median

−62%Database queries per page

$0Extra hardware spend

12 sites, one agency, one developer who had stopped replying

Access recovered and everything migrated in nine days

The situation: No control panel logins, no documentation, no reply from the previous developer in four months. Three sites were still running PHP 5.6 and one had an expired certificate.
What we found: Domains were registered to the agency, which was the opening — registrar-side control meant we could rebuild DNS and mail without the old developer's cooperation.
The decision: Migrate in batches of three rather than all at once, lowest-traffic sites first, so any surprise hit the least important site. Every site came up on a supported PHP version.

12 / 12Sites recovered

9 daysStart to finish

0 minUnplanned downtime

A trades business quoting from a form nobody was receiving

Six weeks of missed enquiries found in an afternoon

The situation: Enquiries had "gone quiet". The owner assumed the market had softened and was about to spend on advertising.
What we found: A plugin update had changed how the form sent mail. The page still showed a thank-you message; the mail was being silently rejected by the receiving server's SPF check.
The decision: Fix the sending path, then add a database record of every submission so a mail failure can never again mean a lost enquiry — plus a monthly automated test submission that alerts us if it doesn't arrive.

6 weeksOf enquiries recovered from logs

1 afternoonTo diagnose and fix

A membership site with 3,000 accounts and a compromised install

Cleaned, hardened and back online the same day

The situation: Google had flagged the site as deceptive. Members were seeing redirects to a third-party page on some devices but not others.
What we found: An abandoned theme with a known file-upload vulnerability, and injected code that only fired for mobile user agents arriving from search — which is why the owner never saw it.
The decision: Restore from a pre-compromise backup rather than clean in place, because a cleaned install you can't fully verify is a liability. Then close the vector, rotate every credential and re-submit for review.

Same dayBack online, clean

0Member accounts lost

About the anonymity. Client names are withheld at their request, not to make the work sound bigger than it was. Every figure above is from before-and-after measurement on the live site — page timings from server-side logs, not synthetic tests. If you're evaluating us seriously and want a reference, ask: some clients are happy to speak privately even when they'd rather not appear on a website.

How we decide

We'd rather show you our reasoning than our certificates

Anyone can list technologies. What's harder to fake is a trade-off you can explain — including the times the impressive option was the wrong one.

This website is one static HTML file per page

No build step, no framework, no dependency graph. It loads in well under a second and it will still work, unmodified, in ten years.

A React rebuild would look more current and would need a dependency update every six weeks, forever, on a five-page site nobody asked to be interactive. We chose the boring option deliberately, and we'd tell you to do the same.

We talked a client out of a $30k rebuild

They'd been quoted for a full headless rebuild to fix a slow store. The actual problem was two plugins and a missing index — about six hours of work.

The rebuild would have fixed it too, eventually, and been far more profitable for whoever did it. Diagnosing before prescribing is the whole job; if we get that wrong, nothing downstream can save it.

We restore rather than clean, when a site is hacked

Cleaning a compromised install in place is faster and looks decisive. But you can never fully prove you found everything, and the second call is always worse than the first.

Restoring from a known-good backup and closing the vector takes longer on the day and is the only version we'd stake our own name on.

We keep PHP current, but never silently

An unsupported PHP version is a security problem, so we move sites forward. We also never do it without warning you, because a major version jump can break an old plugin in ways only you would notice.

Staged first, tested, then switched with a rollback ready. Slower than flipping the version in a panel — and the reason we've never had to explain a broken checkout.

Twenty-three years of building for New Zealand businesses, and the most valuable thing we sell is still knowing which problem you actually have.

Recognise your site in any of that?

Tell us what you're running and what's going wrong. You'll get a straight answer about what's involved before you commit to anything.

Get in touch