What really drives the price of a custom module
Two requests that fit in the same sentence can demand wildly different amounts of work. It isn’t the number of screens or the length of the text that decides, but where the module hooks in and what it does with the data.
First factor: where the module has to slot in
Adding an information block on a product page and changing how an order total is calculated are not the same order of work. The first attaches to a display point, can be checked by eye, and has no consequences if the theme changes. The second enters cart calculation and ripples into the invoice, the accounts, refunds and credit notes. That is why I always ask whether the function touches money: as soon as the answer is yes, the verification work weighs more than the build itself.
Same logic in admin: showing an existing list with one extra column is quick; creating a screen that writes into core tables means handling permissions, logs, input validation and concurrency errors.
The factors I look at first
-
Impact on amounts
Prices, tax, shipping, discounts: any function that changes a total must be verified on the order, the invoice, the credit note and the statistics.
-
Number of hook points
A function visible on the product page, in the cart, at payment and in the confirmation email is four integrations, not one.
-
Exchanges with an outside system
A third-party API means handling outages, timeouts, replays and expiring credentials. A poorly documented API adds an observation phase on top.
-
State of the existing site
A directly edited theme, layers of accumulated overrides or an end-of-life PHP version add work before the module’s first line is written.
Data volume, routinely underestimated
A process that works on three hundred products can collapse on a hundred thousand. Past a certain volume the question is no longer «does it work» but «does it fit inside the execution time and memory the server allows». That forces the work to be cut into batches, with progress tracking and the ability to resume where it stopped. On a large catalogue that batching is not optional, and it easily doubles the technical part of an import or synchronisation module.
Multilingual and multi-store setups play the same role: they don’t change the function, they change the number of cases to write and to test.
Related pages
-
Scoping a module requirement
The information to gather so that a quote is possible at all.
-
Buy a module or have one built
Pricing only makes sense once the off-the-shelf option has been ruled out.
-
Rates and terms
How I bill depending on the nature of the work.
-
Bespoke development
What the engagement covers, from scoping to going live.
Frequently asked questions
Why can a «simple» module cost a lot?
Does the price include future changes?
Can I cut the cost by accepting fewer features?
Does the module’s code belong to me?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.