Fifteen years running one retailer’s entire web stack
The problem
A growing retailer with no in-house IT function, whose storefront, hosting, company mail and advertising data all had to work together and had been bought as separate, unconnected pieces.
The longest-running engagement I have, and the one that keeps every other skill honest: when you administer the server as well as the site, there is nobody to hand the awkward problems to.
The infrastructure
- Two ISPConfig servers — one Nginx for the sites, one Apache carrying the mail stack.
- Outbound mail relayed through Amazon SES, with SPF, DKIM and DMARC aligned across every hosted domain.
- A single socket-only Redis instance shared by the WordPress sites, split by database and key prefix rather than a separate daemon per site.
- Control panel access moved behind Cloudflare Tunnels so the panel port could be closed at the firewall entirely.
- PHP major version upgrades planned as runbooks against the real plugin set, not attempted live.
The storefront
- A brand filter for the catalogue with category-scoped options refreshed over AJAX, transient caching, and compatibility with the site’s pjax navigation.
- Scheduled product imports at real scale — thousands of items per run, attribute mapping, sentence-case title normalisation, and a search reindexing pass afterwards.
- Discount-percentage sorting, payment tracking, and a manual price override that survives the next import.
- Conversion tracking through GTM and GA4 that reconciles against actual orders.
Why it is here
Most consultants can do one of these layers. The value in this engagement is that a slow page, a bounced invoice and a mis-reported ad conversion all get diagnosed by the same person, so nothing lands in the gap between two suppliers.
The outcome
Two self-hosted ISPConfig servers carrying the websites and the mail for roughly thirty domains, plus the WooCommerce storefront on top of them, run as one system by one person who knows every layer.