Vendor module, third-party module or custom build
The same feature can come from three places: a module published by the platform vendor, a module sold by a third party, or code written for you. These three don’t compare on price but on what they guarantee over time.
The module published by the platform vendor
This is the only category I willingly name, because it is tied to the product itself. On PrestaShop, part of the module set ships with the core and follows its releases; on WordPress, the WooCommerce extension is published by the store software’s own maker; on Shopify, some functions are published by Shopify. These modules have a structural advantage: they are tested alongside the platform, and they rarely break on an upgrade, because the same teams build both.
The drawback is that they stay deliberately generic: they cover the standard case and stop there. Trying to make them do something else nearly always calls for an additional module.
The third-party module: what you actually buy
You buy a right of use, rarely a right to modify, and almost never a guarantee of longevity. Three points are worth reading before purchase, because they decide what happens in two years. First, the licence: does it cover a domain, a store, an installation, and does it allow a staging copy. Second, how it is delivered: is the code readable or protected by an encoder, in which case nobody can fix it without its publisher. Third, the update rhythm: declared compatibility with the platform’s latest major release tells you more than any sales page.
A well-kept third-party module remains the best choice for a standard need. It is the badly kept one that costs money, and that isn’t visible at the time of purchase.
What each origin leaves you with
-
Vendor module
Compatibility tracked with the platform, deliberately generic scope, little or no adaptation possible.
-
Third-party module
Function ready immediately, dependency on a publisher, a licence to re-read, sometimes unreadable code.
-
Custom build
Exact scope, sources delivered, no licence to renew, but maintenance that falls to you.
-
A mix of all three
In practice the most common case: an off-the-shelf base, completed by targeted custom work where it falls short.
Related pages
-
Buy a module or have one built
The upstream decision, with the four cases where buying becomes the wrong maths.
-
The module works but its publisher is gone
The options left when the dependency turns against you.
-
Abandoned modules and extensions
The same subject seen from the store security angle.
-
Bespoke PrestaShop module
The third origin in detail, when it is the one that wins.
Frequently asked questions
Why won’t you recommend a third-party module by name?
Is a vendor module always preferable?
Can I have a third-party module I bought modified?
How do I check a licence before buying?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.