# Scoping a module requirement before pricing it

> «I need a module for deposits», «a filter module», «a sync module»: phrased that way, these requests can’t be priced seriously, because they describe an imagined solution rather than a need.

- Source canonique : [https://allaux.fr/en/modules/cadrer-un-besoin-de-module](https://allaux.fr/en/modules/cadrer-un-besoin-de-module)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Describe the problem, not the solution

The first question I ask is never «what should the module do», but «what are you doing by hand today, and where does it break down». The answer often moves the scope: what was asked for as an import module turns out to be a supplier file format problem, and what was asked for as a pricing module is already covered by native price rules that are simply misconfigured.

When the need is real, that description also surfaces the edge cases, which are where most of the effort sits: what happens if the customer cancels, if stock runs out, if the order is placed offline, if the product has several variants, if the store is multilingual.

## What I need to know before pricing

- The platform and its exact version, plus the server’s PHP version
- The theme in use, and whether it was edited directly or through a child theme
- Who enters the information, where it must appear, and who must see it
- What should happen on error: block, alert, or carry on silently
- Whether the function must survive a major platform upgrade
- Whether existing data has to be migrated, and in what format

## The point that changes everything: front, back, or both

A purely internal process, visible only in admin, depends on neither the theme nor the checkout path: it is well bounded, testable and stable over time. As soon as the function has to appear on the customer side, it meets the theme, the cache, the checkout flow and mobile rendering. On PrestaShop that means choosing hooks the theme genuinely calls; on WooCommerce it means depending on actions and filters the theme hasn’t short-circuited with a template override.

That’s why I ask for a screenshot or a rough sketch of where the function should appear. A sentence isn’t enough to tell whether the build takes two days or two weeks.

## Related pages

- **What really drives the price of a custom module** — The technical factors that move the effort once the need is scoped. ([/modules/ce-qui-fait-le-prix-d-un-module](/modules/ce-qui-fait-le-prix-d-un-module))
- **Buy a module or have one built** — Scoping is first of all how you find out whether an off-the-shelf module is enough. ([/modules/acheter-ou-faire-developper](/modules/acheter-ou-faire-developper))
- **Understanding PrestaShop hooks** — The vocabulary of hook points, useful for describing where a function must appear. ([/guides/comprendre-hooks-prestashop](/guides/comprendre-hooks-prestashop))
- **Bespoke development** — The shape of the engagement once the need is described and priced. ([/services/developpement-sur-mesure](/services/developpement-sur-mesure))

## FAQ

### Do I need a formal specification document?

No. One page describing how things work today, what must change, and two or three concrete real-life examples is plenty. It’s the concrete example that reveals edge cases, not the formality of the document.

### Why won’t you price from a single sentence?

Because a figure given without scoping is wrong in both directions: either it is padded to cover the unknown, or it is too low and the gap resurfaces mid-project. Neither helps anyone.

### Is scoping billed?

A conversation to understand the need and say whether it is a setting, an off-the-shelf module or a build is part of answering an enquiry. A genuine technical study, including reading existing code, is chargeable work.

### What if I don’t know my store’s exact version?

It is shown on the admin dashboard, and I can find it myself with read access. I check it anyway, because a stated version and an actual installation often diverge.