Every business has at least one rule that no general-purpose system predicts.<\/p>\n
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.<\/p>\n
Module development<\/strong> is how Odoo handles this. A developer writes a small, separate package of code that adds what your business needs \u2014 without touching Odoo’s own files.<\/p>\n That last part is the whole point, and it is what this article is really about.<\/p>\n A module is a folder of files that Odoo loads alongside its own apps.<\/p>\n 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:<\/p>\n Nothing exotic. But because a module sits beside Odoo rather than inside it, your changes survive upgrades.<\/p>\n This is the one technical concept worth understanding, even if you never write a line of code.<\/p>\n Odoo uses inheritance<\/strong>. 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.<\/p>\n Your code is a layer of instructions applied on top of Odoo’s, not a replacement for it.<\/p>\n Two consequences follow, and both matter commercially.<\/p>\n Upgrades work.<\/strong> 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.<\/p>\n Changes stay traceable.<\/strong> Anyone can see which behaviour is Odoo’s and which is yours, because they are in separate places.<\/p>\n 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.<\/p>\n This is the single most important question to ask a development partner: will the work be in a separate module?<\/strong><\/p>\n There are four ways to change Odoo, and they differ enormously in cost and durability.<\/p>\n Configuration<\/strong> \u2014 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.<\/p>\n Odoo Studio<\/strong> \u2014 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.<\/p>\n Custom module<\/strong> \u2014 a developer writes code. This is where real business logic belongs.<\/p>\n Editing core files<\/strong> \u2014 do not. It is the option that costs the least today and the most every year afterwards.<\/p>\n For a business owner deciding whether to commission work, this is what happens.<\/p>\n Requirements.<\/strong> Somebody has to write down exactly what the module must do, including the exceptions. This is where most bad outcomes are decided \u2014 a vague requirement produces a module that technically works and does not fit.<\/p>\n Development.<\/strong> The code gets written. For a small feature this may be days; for a substantial one, weeks.<\/p>\n Testing.<\/strong> Your own people run real scenarios and confirm the results. Not a demo \u2014 actual cases from your business, checked against what should have happened.<\/p>\n Deployment.<\/strong> The module is installed on the live system, usually with a version-controlled release so it can be rolled back.<\/p>\n Maintenance.<\/strong> 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.<\/p>\n Three questions worth asking about every request.<\/p>\n Is this genuinely how we must work, or just how we happen to work?<\/strong><\/p>\n 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 \u2014 it is free, and there is nothing to maintain.<\/p>\n Does standard Odoo already do this?<\/strong><\/p>\n More often than you would expect, it does \u2014 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.<\/p>\n What does it cost over five years?<\/strong><\/p>\n Not the quote. The quote plus testing at every upgrade, plus the cost of the one person who understands it leaving.<\/p>\n Some features are clearly worth that. Some are not, and it is worth being honest about which is which before you commit.<\/p>\n Four practices separate a system that ages well from one that becomes a burden.<\/p>\n Keep it in modules.<\/strong> Never in core files. This is the rule that protects your upgrade path.<\/p>\n Document why, not just what.<\/strong> In two years nobody will remember why the discount rule works that way. Write it down while the reason is fresh.<\/p>\n Test at every upgrade.<\/strong> Odoo releases a new version each year. Budget for this rather than being surprised by it.<\/p>\n Review periodically.<\/strong> Business rules change. Some custom code serves a process you stopped using. Removing it is as valuable as adding new work.<\/p>\n Four things worth watching for in an existing installation:<\/p>\n 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.<\/p>\n Five questions, before you sign anything:<\/p>\n The answers to those five tell you more than any portfolio.<\/p>\n The best Odoo installations are not the most customised ones. They are the ones where every customization earns its place<\/strong> \u2014 standard where standard works, custom where the business genuinely needs it, nothing kept out of habit.<\/p>\n Have a list of things Odoo does not do out of the box?<\/p>\n Get in touch. We will tell you which ones are genuinely worth building, which ones already exist in standard Odoo, and what each will really cost you over five years.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9071,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9070","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\nWhat a module actually is<\/h2>\n
\n
Inheritance: the idea that matters<\/h2>\n
Where module development sits<\/h2>\n
What development actually involves<\/h2>\n
Deciding what to build<\/h2>\n
Keeping custom code healthy<\/h2>\n
Warning signs<\/h2>\n
\n
What to ask a development partner<\/h2>\n
\n
The balance<\/h2>\n