Between installing Odoo and writing a custom module there is a wide middle ground: settings, Studio, automated actions, server actions, custom fields added through the interface. You can reshape a lot of the system from there without a developer. The appeal is obvious and often correct. The risk is that "no code" feels like "no commitment," and it is not. Every field added through Studio, every automated action, every configured rule is a decision the system now depends on. This note is about where that middle ground ends.
What configuration is genuinely good for
Configuration wins when the change is small, local, and within the grain of what Odoo already expects. A custom field on a model. A filter. An automated action that sets a value when a stage changes. An email template. These are fast to make, visible to the people who own the process, and easy to adjust. Routing all of that through a developer and a deployment would be pure overhead. For changes of this shape, configure.
Where configuration quietly becomes the wrong tool
Configuration stops being the right tool well before it stops being possible. The warning signs:
- Logic spread across many automated actions. When behaviour is implemented as a dozen interacting automated actions, no one can read the whole thing in one place, the execution order is implicit, and a change to one has effects nobody predicted. Business logic wants to live in code that can be read top to bottom.
- It is not in version control. A module lives in git: every change has an author, a date, a reason, and a path back. A Studio change made directly in production has none of that. The system's behaviour now lives partly in a repository and partly in a database, and only half of it has a history.
- It cannot be tested. Code can carry automated tests. A web of automated actions cannot, not really. Logic that matters and can break silently belongs where it can be tested.
- It does not move cleanly between environments. Configuration made in production is hard to reproduce in staging. The environments drift, and the staging instance stops being a faithful rehearsal of production.
How we decide
- Small, local, within the grain, owned by the business: configure.
- Real business logic, anything other code depends on, anything that must be tested or reviewed: build it as a module, in version control.
- A prototype: configuring first to learn the shape of a requirement is fine, as long as it is understood as a prototype and the real version will be code.
The note for the file
The build-versus-configure line is not a line between hard and easy. It is a line between change you need to be able to read, test, and trace, and change you do not. Studio is a real tool with a real place. Its place ends where the system's actual logic begins.