When a company decides to implement an ERP, one of the first questions is usually what functionalities can be directly resolved with the platform and which require additional development.
In the case of Odoo, this question is especially relevant. The ERP manages different areas of an organization, such as sales, marketing, inventory, manufacturing, finance, human resources, and websites. However, just because a company uses Odoo does not mean that all its needs must be resolved within the ERP.
In some cases, customizing Odoo is the most convenient alternative. In others, developing an independent solution and integrating it with the ERP offers greater advantages. And in many projects, the best answer lies in combining both possibilities.
The right decision does not start with technology but by understanding the process that needs to be transformed.
Odoo does not have to solve everything
An ERP centralizes and connects business processes. Therefore, when a need is directly related to areas that Odoo already manages, it makes sense to first evaluate whether it can be resolved within the ERP.
For example, a company may need specific logic to manage inventories, production, purchases, or sales. When that need is part of the main process that already exists in Odoo, customizing it allows the new functionality to integrate naturally with the existing information and flows.
But not all processes have the same nature. A company may also have its own applications, portals for customers or suppliers, specialized systems, or particular processes that require a different experience and logic. Trying to push absolutely everything into the ERP, in those cases, ends up creating an unnecessarily complex structure.
A typical example: a distribution company needs its drivers to capture the delivery at the final point, with photo, signature, and location, even in areas without signal, synchronizing that information with Odoo as soon as they regain connection. Later, we will return to this case to see, step by step, why it ends up being better to build it externally.
Customizing Odoo: when it makes sense
Developing inside Odoo is a good option when the functionality needed is closely related to the processes the ERP already manages.
Its main advantage is integration. The information remains within the same ecosystem and relates to other processes in the organization, which facilitates user operation and prevents them from having to constantly switch between tools.
However, customizing shouldn't mean modifying the ERP every time a need arises. Each additional development has to be evaluated for its maintenance, its evolution, and its relationship to the business's future needs. A solution that works perfectly for the current process becomes a liability if that process changes or if the company expands its technology ecosystem. That's why, before developing, you need to understand not just what the company needs today, but how stable that need actually is.
Developing externally: when it might be better
Some needs are better served by an independent solution: a specific application, a portal for external users, a specialized tool, or a process with a technological logic that shouldn't live inside the ERP.
Developing externally doesn't mean creating an isolated system. The solution integrates with Odoo to exchange the necessary information, and each system fulfills a specific role within the company's technology architecture. This is especially relevant when different users need different experiences: the internal team works in Odoo, while customers, suppliers, or external collaborators interact with an application designed specifically for them.
EmasT works precisely with both capabilities: Odoo consulting and implementation, and custom software development. Its starting point is understanding the challenges of each organization in order to choose the technology that fits the problem, not the other way around.
The decision starts in the discovery
Before deciding where to develop a piece of functionality, you have to understand the full process. A good discovery identifies who's involved, what information is used, what systems participate, what dependencies exist, and what problems show up today. Analyzing only the specific request, without that context, is what leads to the wrong technology decisions.
A requirement may seem simple: “We need a new screen to manage this process.” But upon deeper analysis, questions arise that completely change the initial decision: who will use that screen, where the data comes from, what other processes it affects, what information needs to go back to Odoo, if there are other systems involved, if the process could change, what happens when the users or transactions increase.
What EmasT validates in each discovery, before choosing
It all starts with understanding where the process naturally lives. If it's directly related to the core operations Odoo already manages, it's worth first evaluating a solution within the ERP. If it has an independent logic or is aimed at different users, an external solution usually makes more sense.
Along with that, it matters who's going to use the solution. Internal users, customers, suppliers, and other actors have different needs from one another, and the experience, permissions, and information available to each end up determining whether the functionality should live inside Odoo or in a standalone application.
You also have to look at how stable the process is. If an operation changes constantly, it's worth carefully evaluating where to place the logic, so that each adjustment doesn't require a complex customization. When the process is clearly structured and is part of the ERP's regular operation, customizing it is usually the most efficient path.
Another variable is what systems it needs to integrate with. Odoo coexists with other applications, databases, portals, and specialized tools, and the goal isn't to eliminate everything that already exists, but to define how they should relate to one another, so that solutions share information without duplicating processes.
And finally, what's going to happen as the company grows. A technology solution is designed with more than the initial implementation in mind: more users, more transactions, more products, or more customers change the organization's needs, and scalability has to be part of the decision from the start, not something solved later.
Let's go back to the example of the distribution company. The capture process at the delivery point does not naturally exist in the ERP, it is not part of the administrative flow that Odoo already manages, but rather of a field operation with its own logic. The users are the drivers, not the administrative team, and they need a different experience, fast and designed for a mobile phone in motion. The process is stable in its essence, a delivery always requires a photo, signature, and location, but its execution depends on external conditions like signal, so the solution must operate offline and synchronize later. And as the fleet of drivers grows, that same application must scale without each new route requiring additional customization within Odoo. Analyzing the variables this way, building externally and integrating with Odoo was not a technical preference, it was the conclusion of the discovery.
It's not Odoo against custom development
Framing the decision as "Odoo or custom software" leads to the wrong conclusions. The mistake isn't choosing poorly between the two, it's thinking you have to pick just one, forever. A good architecture isn't the one that concentrates the most functionality on a single platform; it's the one that lets each component do what it's best suited for, with the boundaries between them clearly defined from the discovery stage onward.
The best solution is not always within the ERP
Customizing Odoo can be the right decision. Developing externally can be too. What can't happen is letting the decision be made by whatever tool is trendy, the apparent ease of one implementation, or the eagerness to fold everything into a single system. The business has to make that call.
Because technology shouldn't force the business to adapt to it. Technology should adapt to the way the business needs to grow.
If your operation already coexists with Odoo and two or three more tools, you have surely asked yourself some of these questions. Follow us for the next installment of this series on how to design technology architecture with criteria.