Every Odoo project reaches the same fork. A department needs something the standard system does not do, and there are two obvious routes: find a module in the Odoo apps store that claims to do it, or have the behavior built for you. Both are legitimate answers. The mistake is deciding on the sticker price, because the price of a module is rarely the number that ends up mattering.
What the apps store is genuinely good at
Odoo's app ecosystem is large, and for common, generic problems it is faster than building. Extra report layouts, barcode label formats, connectors to a payment gateway or a shipping carrier, small interface conveniences: these are the same in thousands of companies, and someone has already built and maintained a version of them. A module you install in an afternoon beats two weeks of development that arrives at the same place.
The signals that a module is the right answer:
- The requirement is generic. It describes a category of business, not your specific company.
- The publisher has shipped the module for the last three or four Odoo releases. That track record is the best available proxy for whether it will still exist at your next upgrade.
- The module uses Odoo's own vocabulary and models rather than inventing a parallel structure beside them.
- You would keep the behavior even if you changed partners tomorrow.
Where a bought module gets expensive
Third-party modules rarely cost you on the day you install them. They cost you later, in four predictable ways.
- Upgrades. When you move to a newer Odoo version, every third-party module needs a compatible release or somebody has to port it. A single unmaintained module can hold an entire upgrade hostage while the rest of the system is ready to go.
- Overlap. Two modules from different publishers that both extend the sales order line have never been tested against each other. The conflict is discovered in your database, not theirs.
- The last mile. A module that does 80 percent of what you need is not 80 percent of the job. The remaining 20 percent is now development layered on top of someone else's code, which is slower and riskier than development on top of standard Odoo.
- Support. When it breaks, your partner did not write it. You are waiting on a publisher who works to their own roadmap and their own definition of urgent.
None of this makes buying wrong. It makes "cheap" a claim you should test over three years rather than three days.
What custom development is actually for
Custom work earns its place when the requirement encodes something specific about how your business runs: your approval thresholds, your pricing rules, your production sequence, the exact document a particular customer or authority expects from you. That logic is the reason to run an ERP you control instead of a fixed tool, and it is not something a generic publisher can guess.
A custom change also has a property a purchased module does not: you decide when it changes. Nobody ships you an update that quietly alters your workflow because it suited their other customers.
A test that usually settles it
Read the requirement out loud and ask whether a competitor in your industry would recognize it as their own.
- Word for word, yes: look for a module first.
- In outline yes, in the details no: look for a module, then budget honestly for the gap rather than pretending it will close itself.
- No, this is how we specifically work: build it.
Then ask the second question, which is the one most teams skip: what does this look like at the next version upgrade? If the answer for a module is "we hope the publisher is still around," you have found a real cost that is not on the invoice.
Check standard Odoo before either route
A meaningful share of requests turn out to be neither. Odoo ships a large amount of behavior that is switched off by default or sits behind a settings toggle nobody enabled during implementation. Before you compare a module against a quote, it is worth asking whether the standard system already does this and simply was not configured for it. That is the cheapest possible outcome, and it is common enough to be worth the fifteen minutes. If the answer is no, our custom development service is the route for the logic that is genuinely yours.
How this decision works on Plemo
Plemo is managed Odoo hosting with AI-driven customization built in, and the build-or-install question lands in a specific place in that flow. A request starts as a conversation: the platform asks clarifying questions and pushes back when a request is too broad to build safely. What comes out of that is a written specification you approve before any development starts, and reading the spec is the moment to ask the question in this article. A spec that reads like a generic feature is a signal that something off the shelf may already cover it. A spec full of your own thresholds, sequences and document rules is a signal to build.
Once approved, the change is built and appears in a sandbox copy of your system, so you see it running against your own data before anything reaches production. Usage is metered as credits, which quietly rewards the same discipline: a sharp, bounded request costs less than a vague one.
The short version: buy generic, build specific, and check the configuration before you do either.