# Buying an off-the-shelf module or having one built

> An off-the-shelf module costs less than custom development and covers most common needs. So the real question isn’t «should I build», but «at what point does buying stop being the right call».

- Source canonique : [https://allaux.fr/en/modules/acheter-ou-faire-developper](https://allaux.fr/en/modules/acheter-ou-faire-developper)
- Langue : EN
- Dernière mise à jour : 2026-08-03

## The honest answer: look for an existing module first

A site that always pushed towards custom development would have you pay dearly for functionality already written, tested and fixed across thousands of installations. A payment module, a carrier connector, a consent banner, an accounting export: these are standard needs, and on standard needs the off-the-shelf module almost always wins.

It wins for three concrete reasons: its cost is shared between all its buyers, its edge cases have already been met by other merchants, and compatibility with new platform releases is carried by its publisher, not by you. On PrestaShop, the publisher’s own catalogue and the modules shipped with the core already cover a great deal. On WordPress, the official plugin directory is the same starting reflex. On Shopify, where no server-side code of yours runs inside the store, the marketplace app is the right answer even more often.

## The four situations where buying becomes the wrong maths

The need is specific to your organisation. A discount rule tied to your own pricing grid, an order status that follows your workshop, a business check that exists nowhere else: no publisher wrote that, and the nearest module will force you to bend your way of working to fit its own.

It would take three modules stacked together. Three licences, three publishers, three update calendars and three ways of hooking into the same points of the core: that is the setup that produces the most breakage, and the most expensive to troubleshoot.

The module exists but has to be modified. As soon as customisation touches the module’s own code, updating it becomes a risk at every release. At that stage the purchase price is only a small part of the spend.

The need is the heart of your business. A function your revenue depends on shouldn’t rest on a publisher you don’t know and who may stop trading.

## How I decide, in this order

1. **Check what the platform already does** — Many needs phrased as «I’d need a module» are a native setting that isn’t well known: price rules, customer groups, carriers, order statuses, configuration fields.
2. **Look for a maintained module** — Date of the last release, declared compatibility with your version, a support channel that answers. A module untouched across several major releases is a future project, not a saving.
3. **Price the gap** — If the module covers most of it but not all, I quote the adaptation before it is bought. That is often the point where the decision flips.
4. **Compare over three years, not on the sticker price** — Annual licence, version upgrades, troubleshooting caused by conflicts: a cheap module bought twice a year isn’t cheap.

## I never recommend a third-party module by name

> A publisher can be acquired, change its licensing model, drop a version or disappear. Naming a module as the reference would commit you to something I don’t control. I give you the selection criteria and I review the candidate you have shortlisted; the only modules I name are those published by the platform vendor itself.

## Related pages

- **What really drives the price of a custom module** — The factors that move a development effort threefold for an apparently identical need. ([/modules/ce-qui-fait-le-prix-d-un-module](/modules/ce-qui-fait-le-prix-d-un-module))
- **Vendor module, third-party module or custom build** — The three possible origins and the risks specific to each. ([/modules/module-officiel-tiers-ou-developpement](/modules/module-officiel-tiers-ou-developpement))
- **Bespoke PrestaShop module development** — How a custom build runs once the decision is made. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))
- **Bespoke WooCommerce extension** — The same subject on the WordPress and WooCommerce side. ([/wordpress-woocommerce/extension-sur-mesure](/wordpress-woocommerce/extension-sur-mesure))

## FAQ

### Is a free module a bad choice?

Not in itself. What matters is the maintenance rhythm and whether someone answers. A widely used, regularly updated free extension is often safer than an obscure paid module whose publisher has gone quiet.

### Can I buy a module and then have it adapted?

Yes, and it happens often. You just need to know that some licences forbid modification, and that any change made directly inside the module’s code will be wiped by its next update unless it is isolated properly.

### How do I know whether a module is still maintained?

I look at the date of the last published release, the platform and PHP versions it claims to support, and I read its code: a module using functions removed several versions ago is no longer followed, whatever its listing says.

### Does building always cost more than buying?

Up front, yes, nearly always. Over time, no: custom code has no licence to renew, it belongs to you, and it does only what you need, so it breaks less often.