Lead
Since October 2025, I’ve been Tech Lead on JMA Attachments, a US e-commerce platform selling excavator and skid-steer attachments — about 800 products, most shipped via freight. This is the fuller story behind the numbers on the Work page: what I found, the order I fixed things in, and why.
Starting point
The project didn’t start with a feature list. It started with a full audit, because the codebase couldn’t be trusted yet. A bloated custom module system had grown without documentation, 41 plugins were active with no record of why, and third-party integrations were brittle enough that a small change upstream could break something unrelated downstream. A security review flagged critical issues early — including misconfigured backup and firewall files — and those were fixed before any other work could safely begin. Nothing else was worth touching until the foundation was solid.
Process
From there, I led a small cross-functional team — a front-end developer, a Zoho integrator, a project manager — through a milestone-based process. Every task lived in Jira. Every change went through review before merging. And instead of touching everything at once, we worked one platform area at a time: shipping, then integrations, then Google Shopping, then performance, then data. Slower to start, faster to trust.
What Changed?
Theme foundation
The production theme moved onto a modern build pipeline — Vite, SCSS, a hot-reload dev server — adapted from a starter framework I built myself. Scattered, unbundled CSS and JS became a proper compiled asset pipeline instead.
Shipping architecture
One shipping class had grown to roughly 1,900 lines, handling everything from rate calculation to bill-of-lading generation in a single file. I broke it into about 20 focused, independently testable classes — rate calculation, carrier selection, dispatch, freight-class logic — backed by a real unit-test suite. Nobody has to read 1,900 lines to change a rate rule anymore.
The Priority1 API
Buried in the integration was an abandoned batching function with two real bugs: inverted weight logic and a hardcoded freight class. Fixing it and adding caching meant a 3-item cart that used to trigger 6 separate API calls can now complete in as few as 1 — the mechanism behind the 92% drop in API requests.
Database and query optimization
Per-product thumbnail queries were firing one at a time on every catalog page; batching them into one cut 24 queries per product grid. A filter-count query carried an unnecessary join and sort that never needed to be there. A separate duplicate join was quietly causing memory exhaustion on the highest-traffic catalog pages — the kind of bug that shows up as “the site feels slow sometimes” until someone actually traces it.
Google Shopping
The old setup pushed a product feed to Google once every 24 hours through a plugin. I replaced it with a direct, real-time integration through Google’s own Merchant API, so a price or stock change now reaches Google within minutes instead of a day later. Approved products went from 603 to 806
A pricing bug caught before it reached a customer
While going through the shipping logic, I found a 394 lb product priced at a flat $28 to ship — its real freight cost was closer to $2,496. It had been live like that, unnoticed, every time someone ordered it. One weight-based rule fixed it for good.
Search
The default WooCommerce search had no typo tolerance and took a second or two to return results. I replaced it with a client-side index instead of a paid search service — full story on the search case study — and it now feels instant, not something I’d attach a made-up millisecond number to.
Logging
Debugging traces used to pollute WordPress’s core error log. Now there’s a dedicated, channel-based logging system, configurable per module, so tracing can be switched on or off without touching code.
Security
Every account-creation point on the site — registration, guest checkout, quote requests, social login — now blocks over 80 disposable-email domains, with pattern and subdomain matching, not just a static blocklist.
Performance
Plugin cleanup and a tracking-script audit brought desktop load time down 28% and mobile down 24% in the latest round, with more optimization planned, not finished.
Data
I’m currently building a lightweight inventory dashboard, so marketing never spends ad budget promoting a product that’s already out of stock. Still in progress.
The Takeaway
Find what’s actually broken or at risk first, fix the foundation, then build — with a real number behind each step, not just code shipped.
Running a platform with similar technical debt, or planning something this scope?
I offer a Technical Audit or a full WooCommerce Engineering Review to find out what’s actually going on before committing to a fix.
See it live at jmattachments.com,
Related: WooCommerce for an Excavator & Skid-Steer Attachments Company
Get in Touch