The question comes up with every uncovered need: buy a 90-euro module or have a feature developed from scratch. Put that way, it seems settled in advance. It is not, because the purchase price is only a fraction of the real cost, in both cases.
The four cost items everyone forgets
Custom development is not limited to coding days. Four items are systematically added on top, and they often represent as much as the development itself.
- Specification. Describing the expected behaviour precisely, including edge cases, takes one to three days. Skipping them means paying for them later in back-and-forth exchanges.
- Acceptance testing. Testing the feature on a pre-production environment, reporting deviations, validating fixes. Count 20 to 30% of development time.
- Corrective maintenance. The bugs that surface in real conditions, six weeks after go-live, when nobody has the context in mind anymore.
- The major version upgrade. The most underestimated item. A development built for PrestaShop 8 will have to be reworked for PrestaShop 9. This rework is never budgeted at the time of the initial decision.
An off-the-shelf module has its own hidden costs, lighter but real: configuration time, theme adaptation, and the risk of abandonment by the publisher.
Total cost over three years
Take a concrete need, a performant internal search, and compare over three years.
The module route. Purchase around 150 euros. Configuration and theme adaptation, half a day. Updates included, usually for twelve months and then renewable. PrestaShop 9 upgrade handled by the publisher. Total cost over three years: in the region of 600 to 900 euros, internal time included.
The custom route. Specification, two days. Development, ten to fifteen days for a search with typo tolerance and suggestions. Acceptance testing, three days. That is fifteen to twenty days at 500 euros, between 7,500 and 10,000 euros. Add maintenance and the rework for the next major version, and you exceed 12,000 euros over three years.
The gap is a factor of fifteen. It is only justified if custom development brings something the module does not.
AI Semantic Search — PrestaShopThe search that understands intent, not just keywords€149.00
The five cases where custom development wins
- A business process that is yours alone. A pricing, production or shipping logic that exists nowhere else because it comes from your organisation.
- An integration with an existing system. A homegrown ERP, an industry-specific management tool, a production system. No module knows your data schema.
- A competitive advantage. If the feature is what sets you apart, buying it amounts to sharing it with your competitors.
- An industry-specific regulatory constraint. Pharmacy, plant protection products, firearms, alcohol: obligations that the generalist module market does not cover.
- Exceptional volume. A hundred thousand references or ten thousand orders per day change the technical constraints to the point where generic solutions give way.
The four cases where the module wins
A standard need, shared by thousands of stores: search, reviews, promotions, returns, national regulatory compliance. A tight budget, where the cost gap is decisive. A short deadline, a module deploys within the day. And a team without in-house technical skills, for whom custom development creates a permanent dependency on a service provider.
The middle path
It is often the right one and rarely considered: start from a module and override it for the specific part. You get 80% of the need immediately and only develop the gap.
This approach assumes one condition, to check before buying: that the module exposes proper extension points, hooks or services, rather than requiring a direct modification of its code. A module modified in its files loses its updates, which brings you back to custom development without its advantages.
The questions to ask before buying
- Is the module compatible with PrestaShop 9, or merely announced as such?
- How often has it been updated in the past twelve months?
- Does support answer in your language, and within what timeframe?
- Does the module use class overrides, which conflict with other modules, or only hooks?
- Is there a back-office demo, and not just screenshots?
The last two questions are the most discriminating and the least often asked.
A decision benchmark
If the need can be described in one sentence that other merchants would utter word for word, a module exists and it will be cheaper. If it takes three paragraphs and a diagram to explain, custom development becomes defensible.
The AI Semantic Search module is an example of this trade-off: a feature whose in-house development would represent several weeks, available as a one-day configuration on PrestaShop 8 and 9.
