Most UK companies that ask about Odoo development really want one thing: the software should follow the way they trade, not the other way round. Whether you are a distributor in the Midlands, a professional services firm in London or a manufacturer in Yorkshire, the question is the same. How far do you bend Odoo, and by which route?
The honest answer is to use the lightest route that solves the problem. Odoo offers a ladder of options, and each rung up costs more to build, more to test and more to carry through every upgrade. This page walks through that ladder, explains what it means for updates, and sets out how to judge a developer or integrator before you sign.
The four levels of Odoo customisation
Think of customisation as four levels. Most projects should spend nearly all their effort on the first two.
| Level | What it involves | Code needed | Upgrade impact |
|---|---|---|---|
| Configuration | Settings, workflows, access rights, templates, chart of accounts | None | Minimal |
| Studio | Fields, views, automation rules, reports, approvals | None | Low to moderate |
| Existing extensions | Apps from the community catalogue or an integrator | Installed, sometimes adjusted | Depends on the author |
| Bespoke development | New modules written for your business | Yes | Highest, and it recurs |
Level one: configuration
Configuration is everything you can change without adding anything. Pricing rules, payment terms, warehouse routes, approval steps, document layouts and user rights all sit here. It is the cheapest option because Odoo itself carries it forward when you upgrade.
Before anyone writes a line of code, a good integrator will push your requirements against the standard applications. Our guide to Odoo modules shows what the standard catalogue already covers, and it is often more than a first demo suggests.
Level two: Odoo Studio
Odoo Studio is the no-code tool. According to Odoo's documentation, it lets you customise fields, views, models, applications, automation rules, webhooks, PDF reports, approval rules and security rules without writing code. For a finance director who wants an extra field on a purchase order, or an approval step above a spending limit, this is frequently enough.
Two points deserve attention before you commit.
- Studio is a plan decision. It belongs to the Custom plan, which Odoo lists at 44.90 EUR per user per month, against 24.90 EUR per user per month for Standard (both with introductory discounts for the first twelve months). Odoo also states that installing Studio on a Standard database triggers a move to Custom: a complementary order with a thirty-day delay on an annual contract, or an automatic switch at the next billing cycle on a monthly one.
- Studio changes are still customisation. A field added through Studio still has to be checked on upgrade. No code does not mean no consequences.
Budget for the plan before you design around Studio. The figures on Odoo pricing explain how plans and users are counted, and which hosting choices are available.
Level three: existing extensions
Odoo reports 50 main applications and a community that has contributed more than 50,000 additional applications. That catalogue is a real strength, and also a risk. An extension saves development time, but you inherit someone else's choices, their maintenance habits and their pace of updating.
Before installing a third-party module, ask five questions:
- Is it maintained, and for which Odoo versions?
- Does it modify standard behaviour or add to it?
- Is the source code available for your developer to read?
- What licence applies, and does it suit your edition?
- What happens if the author disappears?
A module that quietly overrides standard logic in accounting or stock is far more dangerous than one that adds a report.
Level four: bespoke development
Bespoke work means a module written for your company. Odoo is built mainly in Python on the server side, with XML for views and JavaScript for the browser interface, and a standard developer toolkit applies. Developers can create modules on top of Odoo and distribute them under the licence of their choice, as long as it is compatible with the edition's own licence.
That licensing point matters in practice:
- Odoo 19 Community is licensed under LGPLv3.
- Odoo 19 Enterprise uses the Odoo Enterprise Edition v1.0 licence, which can be used only with a valid Enterprise subscription for the right number of users.
So a module written for Enterprise is not freely portable. If the day may come when you leave Enterprise, or change supplier, have that conversation at the start.
When bespoke Odoo development is justified
Custom code earns its place when a process gives you a genuine edge and cannot be reproduced with configuration or Studio. Typical cases in the UK include:
- a pricing model that depends on customer, contract and delivery conditions in ways standard price lists cannot express;
- a production or job-costing routine specific to your trade, as described in the manufacturing and industries pages;
- a link to a carrier, marketplace, bank or specialist platform that has no ready-made connector;
- a statutory output your accountant needs and standard reports do not produce.
It is rarely justified when the driver is "that is how our old system did it". Legacy habits are the commonest source of unnecessary modules. Ask what the business outcome is, and whether a small change in process would deliver it with standard features.
UK-specific points to test before building
Compliance is the area where you should lean hardest on standard behaviour. Making Tax Digital for VAT, payroll reporting through RTI and the way your accountant expects the ledgers to look are all things where a custom shortcut can become a liability. Read our notes on Making Tax Digital and your ERP and have your accountant confirm the approach before development starts. If a requirement touches the tax position, specify it with the person who signs the return, not only with the person who uses the screen.
The local setup of Odoo for British companies is covered in Odoo in the UK.
Connecting Odoo instead of rewriting it
A large share of so-called development is actually integration. Linking Odoo to a web shop, a CRM, a bank feed or a warehouse scanner does not need changes to the core of the application.
Odoo's documentation presents JSON-2 as the current external API, with API keys, access rights, database selection and transactions. XML-RPC and JSON-RPC are treated as legacy, and a migration guide to JSON-2 is provided. The external API is one of the features reserved for the Custom plan.
The practical advice is simple. Keep integration code outside the application where you can, talk to Odoo through its API, and avoid patching core behaviour. Our page on Odoo integrations goes further, and the e-commerce ERP guide shows how an online shop usually connects to stock and invoicing.
What customisation does to upgrades
Upgrades are where customisation is paid for. Odoo releases new versions, and each custom module has to be reviewed against the changes. The more a module touches standard models, the more likely it is to need rework.
A few habits keep the bill down:
- Stay close to the standard. Extend rather than replace. Add fields and small behaviours; do not rewrite core flows.
- Keep modules small and single-purpose. One module per business need is easier to test, retire or replace than a single large package.
- Document the reason, not just the code. Record what business problem each module solves, who asked for it and how to check it works. A future developer, or a different supplier, will thank you.
- Test on a copy. Run every change, and every upgrade, on a duplicate of live data before it reaches users. Accountants should be involved in testing anything near invoices, VAT or payroll.
- Review the list once a year. Remove modules that nobody uses, or that a newer standard feature now covers.
The versions and editions page explains how Odoo's release approach affects planning, and support and maintenance covers who looks after the system once it is live.
Best practices in short
- Write requirements as business outcomes before choosing a technical route. Our ERP requirements template helps with this.
- Prefer configuration, then Studio, then proven extensions, then code.
- Treat every module as a long-term commitment, because each one will return at every upgrade.
- Hold the source code in a repository your company controls.
- Agree ownership, licensing and exit terms in the contract.
- Keep a written list of all customisations, updated with each change.
How to evaluate an Odoo developer or integrator
Choosing who builds the work matters as much as deciding what to build. When you speak to candidates, look for evidence rather than enthusiasm.
| Question to ask | What a good answer sounds like |
|---|---|
| How do you decide between Studio and code? | A clear rule: standard first, code only where the process demands it |
| How do you handle upgrades? | A defined routine with testing on a copy of live data |
| What documentation do you leave behind? | Written module descriptions, not just code comments |
| Who owns the code? | You do, or the terms are explicit and acceptable |
| Can you explain a past problem? | A candid account of what went wrong and what changed |
| How do you work with our accountant? | Direct involvement on VAT, ledgers and payroll topics |
Be cautious of anyone who proposes custom development for every request, who cannot say how they test, or who is vague about hosting and access to your database. Equally, be wary of a supplier who refuses all customisation: some processes do deserve code.
Never assume a supplier's credentials from a badge on a website. Ask for the scope of past projects in similar sectors, and speak to a reference where you can. Our guide to choosing an Odoo partner sets out a fuller checklist, and the wider guide to choosing an ERP integrator applies whichever software you pick.
If a project has already gone off course, with modules nobody understands or an upgrade that keeps slipping, an independent Odoo audit and project rescue is a sensible first step before more money goes in.
Getting matched with the right specialist
ERP Integrator is a free service. We do not carry out the development ourselves and we are not affiliated with Odoo; we put you in touch with an independent integrator suited to your project, your sector and your region. You describe what you need, including which parts you think require custom work, and the integrator tests that assumption against the standard product. How it works explains the steps.
A sound first conversation should leave you with a clear view of what is standard, what is configuration, what needs Studio and what, if anything, needs code. That split is the foundation of a project that stays maintainable.
Frequently asked questions
Do I need a developer to customise Odoo?
Not always. Much of what businesses ask for can be done through configuration, and Odoo Studio covers fields, views, automation rules, reports and approvals without code. A developer becomes necessary when the process cannot be expressed with those tools, or when an integration with another system is required.
Will custom development stop me upgrading Odoo?
It does not stop you, but it makes each upgrade a project in its own right. Every bespoke module has to be checked, and often adapted, against the new version. The fewer modules you carry, and the closer they stay to standard behaviour, the smoother the upgrade.
Can I use Odoo Studio on the Standard plan?
Installing Studio on a Standard database triggers a move to the Custom plan. With an annual contract this is a complementary order with a thirty-day delay; with a monthly contract it switches automatically at the next billing cycle. Check this before your team starts building anything.
Who owns a module built for my company?
That depends on your contract, not on Odoo. Developers may build modules on Odoo and distribute them under a licence of their choice, provided it is compatible with the licence of the edition used. Agree in writing who owns the code, who holds the repository and what happens if the supplier stops working with you.
How do I connect Odoo to other UK systems without rebuilding it?
Use the external API where possible rather than altering core code. Odoo documents JSON-2 as the current API, and it belongs to the Custom plan. A well-scoped connector keeps your integration separate from the application, which protects upgrades.
Sources
- Odoo pricing
- Odoo 19 documentation: Studio
- Odoo 19 documentation: licences
- Odoo 19 documentation: external API
- Odoo, about us
Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.