Custom PrestaShop module: how to brief a developer and what drives the cost
What to put in a brief for a custom PrestaShop module or integration, the questions a developer will ask, what makes a module cost more or less, and how to tell a module that survives updates from one that does not.
In short
- A good brief describes the problem and how the shop works today, not the solution: what should happen, for whom, and what goes wrong now.
- Always include the PrestaShop and PHP versions, the theme, and the checkout, carrier and payment modules the feature touches.
- Cost is driven mostly by how many other modules and systems the feature touches, how many cases it must handle and how it will be tested, more than by lines of code.
- Ask how the module hooks into PrestaShop: a module that uses hooks and no core changes is far easier to keep through updates.
Most custom PrestaShop modules start with a sentence like “we need the checkout to do X”. The better the developer understands why, the better the module, and the more accurate the quote. This article is the checklist we would like every client to have before writing to us: what to include in a brief, what drives the cost, and what to ask so the module survives the next update.
Describe the problem, not the solution
A brief that says “add a field to the checkout” leaves out the useful part. Try to answer these instead:
- What should happen? For example: “trade customers should see prices without VAT and order in boxes of 12”.
- For whom? Customers, a customer group, staff in the back office, a warehouse or an external system.
- What happens today? What customers or staff do now, and where it goes wrong. A screenshot or a short screen recording saves a lot of questions.
- How will you know it works? One or two concrete examples: “a customer in group Trade orders 3 boxes, the cart shows 36 pieces at €2.10”.
The technical facts to include
These change the answer more than anything else, so put them in the first email:
- PrestaShop version (for example 8.2.1) and PHP version.
- Theme: Classic, Hummingbird, or the name of a third-party theme.
- Modules the feature touches: checkout, carrier, payment, search, multistore, ERP connector.
- Multistore and languages, if you use them.
- Where it must run: whether there is a copy of the shop for testing.
- Deadline, and whether there is a fixed date behind it, such as a season or a launch.
What drives the cost
The size of a module is rarely measured in lines of code. In our experience these factors decide most of the price:
- How many other modules and systems it touches. A feature inside one page is simpler than one that has to work with three carrier modules, a payment module and an ERP.
- How many cases it must handle. Guests and logged-in customers, combinations, multistore, several currencies and countries each add cases to build and test.
- Where data comes from. Reading data already in PrestaShop is simpler than exchanging it with an external system that has its own rules and failures.
- How it will be tested. A feature that must be tested with real carriers and payments on a copy of the shop takes longer than one that can be checked on a demo store.
A written scope before any work starts protects both sides: what is in, what is out, how it will be tested and what it costs.
Questions to ask the developer
- Does it use hooks, or does it change core files? Changes to core files are overwritten by PrestaShop updates. Overrides should be the exception, used only where no hook exists.
- How is it tested? On a copy of your shop, with the modules you actually run.
- What happens on a PrestaShop update? Who checks it, and how.
- Who owns the code, and can another developer take it over?
- What is the support after launch?
How we work
Our process follows the same steps: a brief, a written scope and quote, development and testing on a copy of your store, then launch and support. Our modules use PrestaShop’s hooks and make no changes to core files, and we also work for agencies that hand us the module or integration part of a client project. The same approach is behind our own modules, Prime OPC and Pack Selector. If you have a feature in mind, see our PrestaShop development services or send us a brief.
Questions and answers
What should a brief for a custom PrestaShop module contain?
The problem in a few sentences, who it affects (customers, staff, a warehouse), an example of what should happen, your PrestaShop and PHP versions, your theme, the modules the feature touches, and any deadline. Screenshots of the current behaviour help.
How much does a custom PrestaShop module cost?
It depends on the scope. A small change to one page costs far less than an integration with an ERP. A developer should give you a written scope with what is included and what is not before naming a price.
Will a custom module survive PrestaShop updates?
It is much more likely if it is built as a standard module: using PrestaShop’s hooks, without changing core files and with overrides only where no hook exists. Ask for it to be tested on a copy of your shop before each update.
Should I hire a freelancer, an agency or a module studio?
Agencies cover design, marketing and the whole shop. A developer or module studio is usually the better fit when the job is one specific feature or integration. Many agencies also hand the module part of a project to specialised developers.