[ E-commerce ]

Magento Development Services

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

2.4.xupgrades on staging first
Freecode and speed audit
Fixedprice for defined work
$20/hrfor small fixes

[ Where Magento stores go wrong ]

Why the store is hard to change.

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.

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.

Full-page cache off

Varnish configured but bypassed, or the built-in cache invalidated on every request by one block that is not marked cacheable.

Extension conflicts

Two modules declaring a preference for the same class, so only one of them works and nobody knows which.

Checkout that stalls

The Place Order button spinning forever because of a JavaScript error in a payment or shipping module's Knockout component.

Broken search

Elasticsearch 7 reaching end of life while the store still depends on it, with OpenSearch never set up or indexed.

Indexers and cron

Indexers on Update on Save, cron not running, and a message queue backing up until prices and stock stop updating.

[ How it works ]

Audit, stage, release.

01  —  Week 1

Audit

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.

02  —  Week 2+

Stage & build

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.

03  —  Release

Deploy & verify

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 ]

What I work on.

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.

Upgrades & migrations

  • Magento 2.4.x upgrades — to 2.4.7 or 2.4.8, including the PHP 8.2–8.4, MySQL/MariaDB and OpenSearch changes each release requires.
  • Extension compatibility — every third-party module checked against the target version, updated, replaced or patched before the upgrade.
  • Magento 1 to Magento 2 — data moved with the Data Migration Tool, custom code rewritten properly rather than ported line by line.
  • Magento to Shopify or BigCommerce — when Magento is more platform than the business needs, with products, customers, orders and 301 redirects.
  • Security patches — Adobe security bulletins applied promptly, admin URL and 2FA locked down, and the code scanned for injected skimmers.

Speed & development

  • Full-page cache and Varnish — hole-punching fixed so category and product pages actually come from cache.
  • Redis and OpenSearch — sessions and cache in Redis or Valkey, catalog search on OpenSearch, sized for the catalog you really have.
  • Frontend performance — JS bundling, image delivery and third-party scripts on Luma, or a move to Hyvä when the theme itself is the bottleneck.
  • Custom extensions — built with plugins and observers instead of class rewrites, so they survive the next upgrade.
  • B2B and checkout — shared catalogs, company accounts and quotes on Adobe Commerce, plus payment, shipping and tax fixes at checkout.

[ Example engagement ]

Upgraded two minor versions, cache finally working.

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.

2minor versions upgraded
3modules replaced
~80%cache hit rate, from under 20%
1.6sfaster category pages

[ Free · 48 hours ]

Get a Magento audit.

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.

Get the audit

[ Pricing ]

Straightforward pricing. $20/hour or fixed.

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

Fixed project price

Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.

Monthly retainer

For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.

$20/hour for small jobs

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 ]

Common questions.

How much does a Magento developer cost?

$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.

How long does a Magento 2.4 upgrade take?

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.

We are still on Magento 1. What are our options?

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.

Can you fix our checkout without rebuilding it?

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.

Why is our Magento store so slow?

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.

Do you work on Adobe Commerce Cloud?

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.

Should we move to Hyvä?

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.

Can you take over from our previous developer or agency?

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.

[ Let's talk ]

Tell me about your store.

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.