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.
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.
-
Buy a module or have one built
Scoping is first of all how you find out whether an off-the-shelf module is enough.
-
Understanding PrestaShop hooks
The vocabulary of hook points, useful for describing where a function must appear.
-
Bespoke development
The shape of the engagement once the need is described and priced.
Frequently asked questions
Do I need a formal specification document?
Why won’t you price from a single sentence?
Is scoping billed?
What if I don’t know my store’s exact version?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.