Standard software meets a non-standard business

Every business has at least one rule that no general-purpose system predicts.

A jewellery business prices by daily gold rate, not per piece. A construction supplier blocks orders when a customer is both overdue and over their exposure limit. A services firm bills timesheets with a different approval chain per client.

Module development is how Odoo handles this. A developer writes a small, separate package of code that adds what your business needs — without touching Odoo’s own files.

That last part is the whole point, and it is what this article is really about.

What a module actually is

A module is a folder of files that Odoo loads alongside its own apps.

Every app in the Apps screen is a module. Sales is a module. Inventory is a module. A custom module your developer writes is the same kind of thing, loaded the same way. It can add four kinds of thing:

• Fields — new information stored against a record
• Logic — rules about what happens when something is done
• Views — changes to what appears on screen
• Reports — new or redesigned printed documents

Nothing exotic. But because a module sits beside Odoo rather than inside it, your changes survive upgrades.

Inheritance: the idea that matters

This is the one technical concept worth understanding, even if you never write a line of code.

Odoo uses inheritance. A custom module does not copy Odoo’s sales order and edit the copy. It says: take the existing sales order, and add this field, and change this calculation.

Your code is a layer of instructions applied on top of Odoo’s, not a replacement for it.

Two consequences follow, and both matter commercially.

Upgrades work. When Odoo releases a new version, the core sales order improves. Your layer is re-applied on top. You get the new features and keep your changes.

Changes stay traceable. Anyone can see which behaviour is Odoo’s and which is yours, because they are in separate places.

Now compare that with editing Odoo’s own files directly. It works today. Then the next version arrives, your edits are overwritten or in conflict, and nobody can tell what was changed or why.

This is the single most important question to ask a development partner: will the work be in a separate module?

Where module development sits

There are four ways to change Odoo, and they differ enormously in cost and durability.

Configuration — settings in the interface. Price lists, payment terms, approval thresholds, email templates. No code. Nothing to maintain. Always check here first, because a surprising amount of what people call customization is really configuration.

Odoo Studio — an Enterprise tool that lets non-developers add fields and rearrange screens by dragging. Good for small additions. Cannot handle complex logic, and heavy use becomes hard to track because nobody records why a change was made.

Custom module — a developer writes code. This is where real business logic belongs.

Editing core files — do not. It is the option that costs the least today and the most every year afterwards.

What development actually involves

For a business owner deciding whether to commission work, this is what happens.

Requirements. Somebody has to write down exactly what the module must do, including the exceptions. This is where most bad outcomes are decided — a vague requirement produces a module that technically works and does not fit.

Development. The code gets written. For a small feature this may be days; for a substantial one, weeks.

Testing. Your own people run real scenarios and confirm the results. Not a demo — actual cases from your business, checked against what should have happened.

Deployment. The module is installed on the live system, usually with a version-controlled release so it can be rolled back.

Maintenance. This is the part nobody budgets for. Every module needs testing at each Odoo version upgrade. A custom feature is not a one-time cost. It is a small permanent one.

Deciding what to build

Three questions worth asking about every request.

Is this genuinely how we must work, or just how we happen to work?

Some processes are a real competitive advantage. Others exist because someone configured it that way years ago and nobody revisited it. Build the first kind. For the second, consider changing the process — it is free, and there is nothing to maintain.

Does standard Odoo already do this?

More often than you would expect, it does — under a different name, or in a place nobody looked. This is where an experienced partner earns their fee, by talking you out of things.

What does it cost over five years?

Not the quote. The quote plus testing at every upgrade, plus the cost of the one person who understands it leaving.

Some features are clearly worth that. Some are not, and it is worth being honest about which is which before you commit.

Keeping custom code healthy

Four practices separate a system that ages well from one that becomes a burden.

Keep it in modules. Never in core files. This is the rule that protects your upgrade path.

Document why, not just what. In two years nobody will remember why the discount rule works that way. Write it down while the reason is fresh.

Test at every upgrade. Odoo releases a new version each year. Budget for this rather than being surprised by it.

Review periodically. Business rules change. Some custom code serves a process you stopped using. Removing it is as valuable as adding new work.

Warning signs

Four things worth watching for in an existing installation:

• Nobody can explain why a customization exists
• Custom code lives inside Odoo’s own files
• Every upgrade turns into a rescue operation
• You are customising to avoid a decision the business should just make

That last one is subtle and common. Sometimes a customization request is really two departments failing to agree on a process, and asking software to keep both versions alive.

What to ask a development partner

Five questions, before you sign anything:

• Will this be a separate module, and can we see the code?
• Who owns the code — us or you?
• What happens at the next Odoo version upgrade?
• How will it be tested, and by whom?
• What does support cost after delivery?

The answers to those five tell you more than any portfolio.

The balance

The best Odoo installations are not the most customised ones. They are the ones where every customization earns its place — standard where standard works, custom where the business genuinely needs it, nothing kept out of habit.