Unpatched versions
Running a 2.4 release that no longer gets security patches, which is how stores ended up skimmed during the CosmicSting wave in 2024.
[ E-commerce ]
Magento 2 stores that stay patched, fast and upgradeable.
Most Magento stores I get asked to look at are not broken by Magento itself. They are two or three minor versions behind, carrying a dozen extensions that override the same classes, with full-page cache quietly disabled because something once broke when it was on.
Free store audit · Fixed-price upgrades · Staging first, always
[ Where Magento stores go wrong ]
Magento is powerful precisely because everything can be overridden. That is also why a few years of extensions and quick fixes turn it into something nobody wants to upgrade.
Running a 2.4 release that no longer gets security patches, which is how stores ended up skimmed during the CosmicSting wave in 2024.
Varnish configured but bypassed, or the built-in cache invalidated on every request by one block that is not marked cacheable.
Two modules declaring a preference for the same class, so only one of them works and nobody knows which.
The Place Order button spinning forever because of a JavaScript error in a payment or shipping module's Knockout component.
Elasticsearch 7 reaching end of life while the store still depends on it, with OpenSearch never set up or indexed.
Indexers on Update on Save, cron not running, and a message queue backing up until prices and stock stop updating.
[ How it works ]
Code, installed modules, patch level, cache hit rate, indexers, cron and server stack. You get a written report of what is risky, what is slow, and what an upgrade actually involves.
All work happens on a staging copy with production data, in Git, deployed through Composer. The live store is never where I find out whether something works.
Deployed in a low-traffic window with a tested rollback, then checkout, search, indexing and page speed re-checked against the audit baseline.
[ What actually changes ]
I work on Magento Open Source and Adobe Commerce, self-hosted or on Adobe Commerce Cloud. The goal is always a store you can keep upgrading, not one that needs a rescue every two years.
[ Example engagement ]
A store on an unsupported 2.4 release with Varnish in place but almost every page bypassing it. Upgraded on staging, three abandoned modules replaced, cache holes fixed.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
[ Free · 48 hours ]
Send me your store URL and version. You get a written review of patch level, extensions, cache and checkout, with the fixes ranked by risk and by effort.
[ Pricing ]
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Hourly rate $20/hoursmall jobs and ongoing work · fixed price for defined projects
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
For a single bug, a short task or ongoing tweaks, where writing a full scope would cost more than simply doing the work. Billed in real time, reported in writing.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
$20 an hour for small fixes, extension conflicts and hourly work, billed for time actually spent. Anything with a defined outcome — an upgrade, a migration, a speed project — gets a fixed price agreed in writing before I start, so the number does not move halfway through.
It depends almost entirely on the extensions and custom code, not on Magento. A clean store can move in a few days; one with thirty modules and theme overrides can take a few weeks. The audit tells you which one you have before you commit to anything.
Magento 1 stopped getting security patches in June 2020, so staying is the one option I would not recommend. The real choice is Magento 2 if you need its flexibility, or Shopify or BigCommerce if you mostly need a reliable store. I will tell you honestly which fits.
Usually, yes. Most checkout failures come from one module's JavaScript, a shipping rate call timing out, or a payment integration on an outdated API. I trace the actual error rather than guessing.
The most common causes are full-page cache not being hit, heavy third-party scripts, unindexed catalog data and an undersized server. I measure cache hit rate and server response time first, because fixing the frontend is pointless if the backend takes two seconds.
Yes. The deployment process and some configuration differ from self-hosted Open Source, and B2B features are Adobe Commerce only, but the code, modules and performance work are the same.
If the Luma frontend is the main reason pages are slow, and you plan to stay on Magento for a few years, it is often worth it. It is a theme rebuild, though, so I would fix caching and extensions first and only then decide.
Yes. I start with a code review so I know what I am inheriting, then keep working in your Git repository with changes you can review.
[ Related services ]
[ Guides on this topic ]
[ Let's talk ]
Send the version, hosting and what is going wrong. You'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually do the work.