Odoo or custom software: choosing without regret

Write down the five processes that matter most to the business — the ones that, if they ran badly, would genuinely cost you money or customers. Then ask one question about each: is this process a standard industry process that we happen to do, or is it a process we have deliberately built differently because the difference is the point?

If most of your five are standard — quote-to-cash, procure-to-pay, inventory and accounting that any competent firm in your industry would recognise — a configurable platform like Odoo will carry you faster and cheaper. If two or more of your five are genuinely differentiated, and you can articulate exactly how and why they differ, you are in custom software territory for at least that part of the system.

The trap is answering aspirationally. Businesses routinely describe standard processes as unique because theirs has accumulated informal steps — a spreadsheet here, a WhatsApp confirmation there. Accretion is not differentiation. If removing the informal steps would lose nothing, the process is standard with extra friction, and a configured platform will usually improve it, not constrain it.

The strong ground

• Standard back-office processes. Sales, CRM, purchasing, inventory, invoicing, accounting and HR as interconnected modules that share one database. The integration between them — a sales order becoming a delivery becoming an invoice without re-keying — is the core value.
• Time-to-value. A disciplined implementation of the standard modules can be live in weeks to a few months, because the software already exists. Most of the work is configuration, data migration and training, not construction.
• The module ecosystem. A large library of community and vendor modules covers common industry needs, which often turns "we'd have to build that" into "we install and configure that."

Where configuration starts fighting the business

The boundary is recognisable: your team starts maintaining parallel spreadsheets to do what the system cannot; every new requirement is answered with a workaround module plus a manual step; or your customisations are so deep that a version upgrade becomes a project in itself. At that point you are paying custom-software costs without getting custom-software fit — the worst quadrant to be in. Good Odoo customisation stays deliberately shallow for exactly this reason: extend where it counts, configure everywhere else.

Worth it

• A genuine process advantage. The way you quote, schedule, price, route or serve customers is itself a competitive asset, and no platform models it without distortion.
• Unusual integration requirements. The system must talk to equipment, legacy databases, government portals or partners in ways standard connectors do not cover.
• IP you want to own outright. The software is, or will become, part of the product or valuation — a platform you operate, not just a tool you use.

Overkill

• The requirements are a list of features, and an existing product already has all of them. Building to match an existing feature set is the most expensive way to arrive at someone else's starting line.
• The business cannot yet describe its own processes consistently. Custom software freezes your process into code; if the process is still changing quarterly, you will be paying to re-freeze it every quarter.
• Nobody will own it after launch. Custom systems without an internal owner and a maintenance budget decay quietly and expensively.

When custom is the right answer, scope it as narrowly as possible around the differentiated process and let standard tools carry the rest — which is how we approach custom software development in practice.

Score each dimension honestly with the people who will run the system, not just the people sponsoring it. No single dimension decides; the pattern across all five does.

1. Process standardisation. What share of your core processes match standard industry practice? Mostly standard points to Odoo; mostly differentiated points to custom.
2. Timeline. Do you need the system working this quarter, or can the business wait six to twelve months for a build? Urgency favours configuration.
3. Budget shape. Odoo concentrates cost in implementation, licensing and hosting — predictable, recurring. Custom concentrates cost in a build phase followed by maintenance — heavier up front, then a standing obligation. Which shape your cash flow tolerates is a real constraint, not a detail.
4. Integration complexity. Count the systems it must talk to, and how unusual those connections are. A handful of standard tools favours a platform; exotic or equipment-level integrations favour custom work for that layer at least.
5. Ownership intent. Is this operational plumbing you want to consume, or an asset you want to own and shape over years? The honest answer here settles many close calls.

A useful rule of thumb: if three or more dimensions point the same way, stop deliberating. The remaining risk is execution quality, not the choice itself.

Most serious deployments land between the poles. Odoo itself is a platform with an open codebase: "use Odoo" can mean anything from pure configuration of standard modules, to a few custom modules for industry-specific workflows, to deep extensions where Odoo is effectively the framework your custom system is built on.

In practice, the line usually sits here: standard modules for sales, accounting, inventory and HR, configured to your chart of accounts and document formats; a small number of custom modules for the one or two processes that are genuinely yours; and integrations built where systems must exchange data automatically. This pattern captures most of the platform's speed and cost advantage while still protecting what makes the business distinct.

The discipline that keeps a hybrid healthy is asymmetry of effort: be ruthless about accepting standard behaviour wherever the process is not a differentiator, and spend your customisation budget exclusively where it is. Teams that invert this — customising standard processes for comfort while under-investing in the distinctive ones — get the costs of both paths and the benefits of neither.

Year-one cost comparisons between the two paths are misleading because the cost curves have different shapes. Compare them across a realistic horizon instead.

The Odoo path

• Year one: implementation (configuration, data migration, training, any custom modules) plus licensing and hosting. The implementation is usually the largest single-year line item.
• Years two to five: licensing, hosting, support, incremental adjustments, and periodic version upgrades. Costs are comparatively flat and predictable, with an upgrade project every few years if custom modules exist.

The custom path

• Year one: discovery and build — substantially larger than an equivalent implementation, because everything is being created, including the unglamorous parts a platform provides for free.
• Years two to five: maintenance, infrastructure, and continued development — a standing cost that is easy to underestimate at the start and painful to remove later. The system also carries an implicit staffing dependency: someone must understand it.

The honest summary: for standard processes, custom software rarely wins a five-year cost comparison, and when the process is genuinely differentiating, the platform rarely wins a fit comparison. Cost is the tiebreaker between options that both fit — it is a poor substitute for fit itself. If the numbers matter for a decision you are weighing now, our guide to what these projects really cost breaks down the budget structure in more detail.