Configure first and build only when configuration cannot do the job. Standard Odoo set up well is cheaper to run and far easier to upgrade. Custom code is sometimes the right answer, but every piece you add becomes something that must be tested, kept working and carried through each new version. Treat it as a long-term commitment, not a one-time purchase.
Configuration versus custom development
Configuration means using what Odoo already offers: settings, extra fields, approval rules, automated actions, templates and print layouts. It needs no new code, and it moves forward with Odoo.
Custom development means writing new code: new behaviour, a new screen, a new report that settings cannot produce, or a connection to another system. It can fit your work exactly. It also needs a developer later.
A simple rule of thumb:
- If a setting or an extra field solves it, configure it.
- If it needs new behaviour or a new screen, consider building it.
- If it is a connection to another system, plan it as a small project.
Before you build, ask these
- Is the process wrong, or is the software wrong? Sometimes the better answer is to change how the work is done.
- Does standard Odoo already do this in another way? Ask the team to show you before you pay for a new feature.
- Does a well-maintained add-on already exist? Using a proven one avoids rewriting what is there.
- How many people will use it, and how often? A feature used by one person once a month is a poor candidate.
- What happens if we do nothing? Be honest about the real cost of the workaround.
What custom work costs later
The bill for custom work does not end at delivery of the feature. It continues each time Odoo moves to a new version.
- Your custom code must be tested on the new version.
- Anything that breaks must be fixed before you switch.
- Your data must be tried on a copy first.
- Each feature that changes core behaviour makes this harder.
The more a custom feature replaces what Odoo does, the more it will break. The more it extends what Odoo does, the less it will. This is why a careful team extends instead of replacing.
How good custom work is built
You can judge the quality of a developer by how they describe their method.
- They extend standard behaviour instead of rewriting it.
- Each piece does one job.
- It is documented in plain language, so someone else can pick it up.
- A second person reviews each change before it goes live.
- Each Odoo release gets its own tested version.
- Shared parts are reused when several clients need the same thing.
Ask to see how upgrades are planned for custom work. If the answer is “we will see”, be careful.
Signs a request should not be custom
- It copies a screen from your old software exactly.
- Only one person asked for it.
- The need can be met by a report or a saved filter.
- Nobody can say what business result it improves.
Signs it is worth building
- The process is how you earn money and standard Odoo cannot support it.
- Many staff use it daily.
- The workaround costs real hours every week.
- It can be built as a small extension.
Where Teapot Techies fits
We configure standard Odoo wherever it fits and write custom features only for what the process genuinely needs, keeping them small. Our Odoo engineering page describes what we build and how we keep it easy to own, and our Odoo implementation work starts with a fit and gap review so you know which is which before you commit.