01. What Odoo does very well
Odoo covers a wide scope with one tool: sales, purchasing, stock, accounting, projects, human resources. For a company whose processes resemble those of most companies, that is a considerable advantage — the essentials already exist and are configured rather than built.
It also benefits from an ecosystem: many integrators, a community, third-party modules, abundant documentation. You are not dependent on a single supplier, and that is a serious argument.
Finally, the entry cost is predictable. Licences are published, configuration is quotable, and a standard deployment runs on known rails.
- A very wide functional scope, available immediately.
- A community and several possible integrators.
- A published, predictable entry cost.
- Updates and fixes handled upstream.
02. Where the cost moves
The trap of a modular package is not its published price: it is the gap between what it does and what you do. That gap is closed by configuration as long as it stays small, then by specific development, and that is where the budget changes nature.
A custom module grafted onto Odoo has to be maintained at every version upgrade. What was a one-off development becomes an annual charge, and that charge appears on no initial quote.
The second shift is human. A package imposes its vocabulary and its sequence of screens. When they drift too far from how you work, teams route around them — a spreadsheet reappears alongside, and you are paying for an ERP that holds only part of your data.
03. The six questions that decide
These questions need no technical expertise. They are answered internally, and their answers almost always decide on their own.
- How many of your key processes work like your competitors’, and how many are your difference?
- How many users, and for how many years? A per-user licence is compared over five years, not one.
- What happens if the module you need is maintained by nobody in two years?
- Will your teams accept changing how they work, or must the tool follow theirs?
- What proportion of the package will you actually use?
- Who takes over maintenance if your integrator stops trading?
04. A third way, often the right one
The debate is framed as binary, when in practice it rarely is. Many companies gain by taking a proven base for what is standard, and building the part that sets them apart — connecting the two rather than merging them.
Accounting, purchasing and payroll do not need reinventing. The pricing rule specific to your sector, the approval circuit imposed by a client, the traceability your activity requires: those are the pieces that justify development.
Drawing that line requires knowing where it runs, and that is exactly the work of a scoping phase. A supplier who answers “all custom” or “all package” before knowing your processes is selling their catalogue, not your need.
05. What we answer, and why
SigmaGravity deploys its own solutions and builds custom software. That could suggest we systematically advise against market packages: it would be dishonest, and it would show on the first project.
When a package covers your need without contortion, it costs less and deploys faster. We say so, and we sometimes lose the work — that is the price of advice worth something.
Custom development earns its place in three situations, and only those: when the per-user cost durably exceeds amortising a build, when bending the market tool costs more than building, and when the specificity to be automated is precisely what sets you apart.