I chose Odoo for AC Cycles, and I have chosen it again for Polyphony. Between those decisions, two years of sales, solution architecture, functional work and coding for other businesses have given me a much closer acquaintance with the platform. That experience has strengthened my enthusiasm. The adaptability, agility and openness that first attracted me have become more valuable as the problems I work on have become more demanding.
There is a different quality to a software decision when you will have to live with its consequences. At AC Cycles, a rental booking was not simply a record of a sale. It had to connect with availability, preparation, an agreement, payment and the customer arriving to collect a bicycle. Each part could work reasonably well in isolation while the overall experience remained dependent on someone remembering to join it together. I have written about that implementation elsewhere; what matters here is the lesson it established about the relationships between activities.
Polyphony is a different business, but those relationships matter just as much. A commercial commitment needs to remain intelligible as it becomes work, uses people’s time and eventually becomes an invoice. Choosing Odoo again is partly a judgement about its present capabilities and partly a judgement about the room it leaves me to develop the business.
I am not expecting a software vendor to have anticipated everything I might want to do. I am choosing a platform that gives me a practical way to act when it has not.
The value is between the applications
I do not assess Odoo primarily as a catalogue of applications. What interests me is the possibility of treating the business as a connected operation rather than a collection of departments, each maintaining its own account of what is happening. Odoo’s integrated suite provides a foundation for that, although installing the applications is not the same as establishing a coherent way of working.
An order is simultaneously a promise to a customer, a demand on capacity, a possible purchasing requirement and an eventual financial consequence. Those are not competing interpretations; they are different responsibilities arising from the same event. I want a system in which their relationships can be understood and managed without continually reconstructing them across organisational boundaries.
This is close to the thesis behind Polyphony. Independent parts do not need to lose their character in order to contribute to a coherent whole. Odoo can act as a conductor in that arrangement, coordinating the points at which activities depend on one another. It does not decide what the business should value, and it does not remove the need for people to exercise judgement. It gives those decisions somewhere connected to operate.
Nor does coherence require putting everything in Odoo. A specialist application may have a very good reason to remain specialist. The architectural question is where each responsibility belongs and how the connections should work, not how many applications can be eliminated. I am enthusiastic about Odoo as a centre of coordination, not as an excuse to make every problem look like an ERP requirement.
Openness matters because it creates agency
The practical value of openness is agency: the ability to understand a system, make informed choices about it and take responsibility for changing it.
A vendor cannot accept every feature request. It has to consider the coherence of the product, the needs of other users and the cost of maintaining what it introduces. A request can be entirely sensible for an individual business and still be unsuitable for the general roadmap. I do not regard that as a failure of the vendor. The problem arises when the end of that conversation also becomes the end of the business’s options.
Odoo gives me another avenue. I can investigate the behaviour, establish whether the requirement really needs an extension and, where it does, undertake that work myself or with a capable partner. Its module-based extensibility is important because it allows the discussion to move beyond waiting for a feature to become someone else’s priority.
That freedom is not a reason to customise impatiently. My first preference is to understand the native capability properly. Development creates something that must subsequently be tested, maintained and reconsidered as the platform changes. But when a requirement is essential, I want the decision to turn on its value and feasibility, rather than solely on whether the vendor will agree to build it.
There is an important distinction within the word “open”. Odoo Community is open-source software under the LGPLv3 licence; Enterprise adds functionality under a separate commercial licence, with conditions on use and redistribution. The ability to inspect and extend a system should not be confused with unrestricted ownership of everything it contains.
My attraction is therefore practical rather than doctrinal. I value being able to understand the machinery on which the business depends, and having meaningful options for changing it. That does not eliminate dependence on expertise or suppliers. It changes the terms of that dependence.
Affordability changes what is worth attempting
The licence cost was a material part of both choices. In my assessment, Odoo’s per-user pricing is one of its strongest commercial differentiators. Its paid Standard and Custom plans include Odoo’s application suite within a per-user subscription, rather than requiring a separate subscription for every application.
For me, this has meant both spending less on licences than the alternatives I considered and being able to attempt more. Those benefits should not be conflated. One reduces the cost of doing something already planned; the other changes the range of ideas it is reasonable to investigate.
When the licensing barrier is manageable, an additional workflow need not begin with a substantial new software commitment. There is more room to examine an operational idea, learn from a limited implementation and decide whether it merits further investment. The relevance to a growing business is considerable: the organisation can begin developing capability before it has the scale to justify a much larger fixed commitment.
That is not an argument that ERP is cheap in every meaningful sense. Understanding requirements, preparing data, configuring, testing, training and operating the result still require work. My preference is to spend deliberately on that work, especially where it improves the business or supports a genuine difference, rather than exhausting the available budget simply obtaining access to the software.
Standardise what is ordinary; develop what is distinctive
Odoo does not have equal depth in every area. In my experience, whether that matters depends less on the length of a feature list than on the role an activity plays in the particular business.
An area the organisation encounters occasionally may be adequately served by a relatively straightforward application. A mature, widely shared business process may need little more than a sound standard implementation. The same level of functionality can be entirely appropriate in one context and insufficient in another.
I would expect the most demanding questions to arise around the way a business genuinely differentiates itself. If an unusual service model, allocation method or customer experience is central to its advantage, why should a general-purpose vendor already have implemented the precise expression of that advantage? I would be more surprised to find it perfectly represented in the standard product than disappointed to discover that some work remained.
That is not a claim that every competitive advantage requires custom software. Expertise, relationships and the skilful combination of ordinary capabilities can be difficult to reproduce. Bespoke code, meanwhile, can be expensive without being distinctive. The important distinction is between work that supports a meaningful advantage and work that merely preserves a familiar habit.
For the former, I expect to take responsibility for creating what the business needs. That might mean a carefully bounded extension, a specialist system connected to Odoo, or a different way of combining existing functions. The value of a capable general platform is that it gives this distinctive work a foundation without requiring the business to rebuild everything around it.
Some omissions are simply deficiencies. If a necessary control is absent, a basic workflow is unreliable or a specialist requirement cannot be met sustainably, openness does not make the problem disappear. An extension is one possible response, not a moral obligation to rescue the platform from every limitation. The useful opportunity lies in being able to assess the gap and choose a proportionate response—including choosing another tool.
Hosting is an architectural choice
I have found deploying Odoo on my own infrastructure unusually approachable. That matters both when establishing an operating system for a business and when creating an environment in which an idea can be tested. It gives me access to the application and database, as well as control over the surrounding services.
I do not confuse that experience with a claim that every business owner should administer servers. I bring technical experience to the task. Getting an application running and making it dependable are different responsibilities; I would not consider a deployment complete without attending to security, backups, recovery and maintenance.
Cloud hosting remains a valid alternative. Odoo offers its managed Online service and Odoo.sh alongside on-premises deployment options; the appropriate choice depends on the control, development freedom and operational responsibility required. Under its published commercial plans, external API access is a Custom-plan feature, so the architecture must take account of the subscription as well as the hosting choice.
The distinction I care about is not local hardware versus a distant data centre. A self-managed cloud deployment can also provide substantial control. What matters is which parts of the system I can access, which decisions remain mine and which responsibilities a provider is accepting. I want hosting to follow the needs of the architecture, rather than discovering late in the work that the hosting arrangement has determined the architecture for me.
Progress and compulsion are different things
Odoo’s development pace is part of its appeal. I like a platform that continues to acquire capability and gives me reasons to reconsider what can be done natively. Successive major releases and more frequent Online releases are part of its published development and support model.
I am less enthusiastic about compulsory upgrades. A new release may be a welcome technical development while arriving at an inconvenient operational moment. The business has its own commitments, training needs and capacity for change. Maintaining a system matters, but the value of new functionality and the cost of adopting it are separate questions.
The distinction also needs to be technically accurate. Upgrade requirements differ across hosting arrangements. Odoo Online can require upgrades to a deadline; self-hosting provides more control over timing, but does not remove maintenance responsibilities or the consequences of leaving standard support. Extended support has its own terms and costs.
My response is to treat change as something to design for. Keep extensions purposeful, preserve the reasoning behind them and test the work that matters to the business. When native functionality becomes sufficient, be willing to retire something previously worth building. An extension does not need to remain permanent to have justified its existence.
That is how rapid development can become an advantage rather than simply a recurring migration bill. It needs an architecture that can absorb change and an operating plan that makes room for it. Enthusiasm for the release notes is not a substitute for either.
The ecosystem needs a more honest promise
My view is that the consulting ecosystem around Odoo still has maturing to do. I am not using maturity as a synonym for size or longevity. I mean the ability to distinguish what is easy to demonstrate from what is difficult to make dependable in a real organisation.
The promise I would like to hear more often is not “this is easy”, but “this is hard, and we can help you through it”. That is not a defence of needless complication. It is an acknowledgement that business change involves understanding incomplete information, resolving competing requirements and helping people take responsibility for a different way of working.
An approachable interface is valuable. So is an accessible platform. Neither eliminates the need for business analysis, architectural judgement or careful delivery. Treating accessibility as evidence that the whole undertaking is simple risks undervaluing precisely the work that makes the software useful.
For me, the opportunity is to develop that capability across the ecosystem: better discovery, stronger mentoring, clearer responsibilities and a more disciplined distinction between a useful extension and an avoidable one. That is a constructive response to immaturity. It asks us to improve the practice around the platform rather than praising its potential and leaving clients to encounter the difficult parts themselves.
A future in which the ERP is less visible
The same openness is why I am interested in Odoo as the foundation for a more agentic way of working. This is the direction I am exploring through OrchestratorOS: people expressing an intention, with software helping to interpret it and carry out the appropriate work across business systems.
Consider an instruction such as: “Review next fortnight’s commitments, identify the work still missing essential inputs, and prepare the follow-up messages for my approval.” This is an illustrative design goal, not a claim that the whole capability is already delivered. It describes the task in the person’s terms, rather than as a sequence of screens they must navigate.
A headless ERP, in this sense, does not dispense with the business system. It separates that system from an assumption that every action must begin in its standard interface. Odoo already exposes data and business methods through external interfaces. That makes alternative interactions an architectural possibility; it does not make reliable autonomous operation an automatic consequence.
On-premises deployment is attractive to me because access to both the application and its data gives me more room to examine and build those connections. Direct database access is not, however, a licence for an agent to alter business records indiscriminately. Odoo's documentation warns that bypassing its application layer can bypass access controls and other important behaviour. Reading authorised data and executing a business transaction are different responsibilities.
The design I want would use controlled application operations, appropriate permissions and explicit approval where the consequences require it. It would preserve evidence of what was requested and done, and ask for clarification when the instruction or available information was insufficient. A convenient interface should not quietly enlarge anyone's authority.
An agent needs more than access to rows in a database: it needs the relationships and rules that make those records meaningful. A purchase order is not merely a collection of fields, and an instruction to prepare one is not permission to commit the business to spending money.
I do not expect every screen to disappear. People will still need to inspect, reconcile, challenge and decide. I am interested in reducing the work of navigating the system while retaining the discipline that makes it trustworthy. In that future, the ERP may become less visible to the user while remaining central to the operation.
Why I chose it again
My enthusiasm for Odoo is not an enthusiasm for a world without difficult decisions. It is an enthusiasm for a platform that leaves me equipped to make them. The connected foundation, the manageable licensing threshold and the ability to investigate and extend are useful separately; together, they change what I can reasonably attempt.
That is why I chose it for Polyphony after working with it in my own business and in other organisations. I know more about the work involved now. I also have a clearer sense of what its openness makes possible.
Odoo does not need to pretend that building a better business is easy to make a compelling case for itself. It can provide much of the ordinary structure, leave room for what is genuinely different and give the business more agency over the result.
To me, that is a stronger proposition than the sales pitch, and the reason I remain convinced of its value.