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

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.