When a custom module beats a bought one
A module is a separate piece of code that adds functionality to Magento without changing Magento's core files. That makes updates safer. Still, not every problem needs custom code.
- No module covers your situation, for example your own order flow in the warehouse.
- A bought module does most of it, but a small part is missing and you have to work around that gap with every update.
- A bought module loads scripts and queries you do not use and slows the shop down.
- Magento itself has a bug or a gap, and you want a targeted fix without touching the core.
- Two systems need to exchange something that does not work out of the box.
Is there a good module that fits? Then I will recommend it. Custom code is maintenance you buy along with it, so I only build what pays for itself.
How a module works in Magento 2
A module registers itself with Magento through a few configuration files. After that it can step in at fixed points: a plugin changes how an existing function behaves, an observer reacts to an event (such as a placed order), and templates decide what the visitor sees.
That sounds tidy, but Magento runs many modules at the same time. Two modules that change the same function can cancel each other out. You will not see such a conflict in your own module's code, only in how the whole shop behaves.
That is why I read how the existing modules fit together before I write a single line. It is the difference between a module that works on an empty install and one that works in your shop.
Modules I wrote myself
These come from the shop I work in myself. They show what kind of problems a custom module solves.
- Content Security Policy and SRI hashes: the CSP is the set of rules that decides which scripts your shop may load, and an SRI hash is a checksum the browser uses to verify a file has not been altered. My module fixed a bug where the hashes no longer matched the delivered files after a deploy.
- Canonical tags on CMS pages: a canonical tag tells Google which URL is the original. Magento does not set one on CMS pages by itself. My fix does.
- A 'gate' for third-party scripts: chat widgets, trackers and other external scripts only load once a visitor interacts with the page. The first view no longer waits on other people's code.
- A custom warehouse module for order picking, gathering orders from the shelves. It is still in development.
None of these is a product you can buy. They exist because the shop asked for them. That is how I work for you too.
How I work on your module
A module that works in a test shop can still go wrong on production. So every project follows the same steps.
- Read first: how the existing code and modules fit together, and which ones touch the same part as the new one.
- Changes go to a test environment first, with a copy of the production situation.
- Rollout without taking the shop down. Visitors and orders keep flowing.
- No full cache flush on production. A flush throws away all stored pages, which makes the shop slow for a while. I refresh only what is needed.
After the rollout I check that the module does what it should, on the pages that matter.
From practice
A Magento 2 shop with 328 active modules
This is the shop I work in myself: Magento 2.4.7 with over 3,400 products, about 13,600 product pages across four language versions and 328 active modules. The client stays anonymous, the numbers are real.
With that many modules, a new module is never an island. Before I write anything, I find out what already hooks into the same page or the same event.
LCP is the time until the largest element is on screen. It was 14 to 16 seconds and is now 2.14 seconds for real visitors. Custom modules do not have to make a shop heavier. Well written and tested, they keep it light.
What I do not do
A module is code you will keep running. So I stick to a few limits.
- Edit Magento's core files. That turns every update into a risk.
- Build a module when a good one already exists that fits.
- Develop or test directly on production.
- Run a full cache flush on production.
- Remove bought modules from your shop unless you ask me to.
If custom code is not the best route, I will say so.
Scope and price
What a module costs depends on how many parts of Magento it touches, how many other modules sit in the same corner, and whether a connection to an external system is involved.
I do not sell fixed packages for Magento work. After a first conversation I know what the module has to do and we agree on the scope. More on how I price is on the pricing page.