Custom ERP vs Odoo: When Does Building Your Own ERP Make Sense?

Odoo is a family of business applications — sales, purchasing, inventory, invoicing, manufacturing and many more — that work from a shared database, so a business installs the apps it needs now and adds others later. Choosing Odoo is therefore not one decision but three: which edition, which hosting option, and how far you intend to change what comes out of the box.

That modularity is why it appears on so many ERP shortlists. A distributor can begin with sales, purchasing, stock and invoicing; a manufacturer can add production; a growing group can add further apps as teams arrive. The apps are designed to pass records to one another, which is the central promise of any ERP: an order raised once and read by every team that touches it.

Community and Enterprise

Odoo comes in two editions. Community is the open-source edition and forms the core of the product; Enterprise is a licensed edition built on that core, adding further apps and features — Odoo Studio among them — together with access to Odoo’s own hosting, support and upgrade services. Odoo allows a business to switch between editions, but the apps and features a design relies on should be checked against the edition it will actually run, because the comparison shifts from release to release.

Three ways to host it

• Odoo Online is hosted and run by Odoo. It is intended for standard apps and does not accept non-standard modules, so adjustment happens through configuration and, depending on the plan, Studio.
• Odoo.sh is Odoo’s managed platform for Enterprise databases that need custom code, with branches and an online editor for developing and testing modules.
• On-premise means you, or a partner, install and run Odoo on infrastructure you control, with either edition and whatever custom code you are prepared to maintain.

The hosting choice quietly decides how far up the spectrum you can travel. A business that expects to add its own modules is ruling Odoo Online out before a line of code is written, and a business that chooses on-premise is taking on the servers, backups, patching and monitoring that a hosted option would otherwise carry for it.

Odoo Studio

Odoo Studio is Odoo’s no-code customisation tool, available with Enterprise. It lets a trained administrator add and change fields, views, models, automation rules, webhooks, PDF reports, approval rules and security rules inside the apps a business already uses. Depending on your subscription, adding Studio can change the plan you are on, so confirm that before a design assumes it.

Studio matters here because it moves a surprising amount of work out of the “extend” column and into the “configure” one. A change made in Studio still lives inside the platform, which is a different obligation from code the business commissions — though every meaningful change, however it was made, still deserves a test when the platform moves to a new version.

A custom ERP is a system designed and built for one business: its own data model, workflows, screens, permissions, integrations and reports, owned by that business rather than licensed from a vendor. The word “custom” describes how it starts. What decides whether it succeeds is everything that comes after the first release.

A custom ERP is one kind of software shaped around a single business. What sets it apart from other custom applications is that several teams share it: sales, operations, procurement, finance and management all read and change the same records, so a decision made in one place becomes true everywhere else.

Building one is not the same as heavily modifying a platform. In a custom build there is no underlying product to fall back on. Every record type — customer, item, order, job, invoice, supplier — exists because somebody designed it, and every rule that connects them exists because somebody wrote it, tested it and will have to change it when the business changes.

What you design

You decide how records relate, which states a job moves through, who can approve what, what the history records and how the system talks to accounting, the website, logistics providers and anything else the business keeps. That freedom is the whole attraction. A process no platform models well — an unusual production sequence, a service delivered across several partners, a pricing structure that is itself the product — can be represented exactly as it runs.

What you inherit

You also inherit the lifetime obligations a platform vendor would otherwise share with you:

• hosting, monitoring, backups and recovery;
• security updates to the frameworks, libraries and infrastructure underneath;
• bug fixes, and changes whenever a tax rule, a regulation or a partner’s interface moves;
• documentation good enough that a new developer can change the system safely;
• a roadmap, a release process and somebody accountable for both.

None of that is a reason not to build. It is the reason a custom ERP belongs at the far end of the spectrum rather than at the start of the conversation. A business that can fund and staff those obligations for as long as it runs the system is acquiring an asset. A business that cannot is acquiring a liability that happens to look like one.

The most dependable route to the right answer is to treat the decision as a ladder rather than a contest: standardise first, configure next, extend where you must, and build only where the first three steps genuinely cannot carry the process. Each rung buys a closer fit, and each costs more to own.

1. 01 Standardise. Adopt the standard process wherever yours is not a differentiator.
2. 02 Configure. Shape Odoo with its settings, apps and no-code tools.
3. 03 Extend. Add custom modules and integrations on top of Odoo.
4. 04 Build. Build custom only where the first three cannot carry the process.

The ladder is climbed process by process, not once for the whole company. It is entirely normal for one business to standardise its accounting, configure its purchasing, extend its warehouse picking and build a single custom application for the service that actually wins it customers. Framing the question as “Odoo or custom?” hides that possibility. Framing it as “how little can each process change?” brings it into view.

The ladder also changes the conversation inside a leadership team. Operations leaders tend to argue for fit, finance heads for predictability, founders for speed and control. Each instinct gets a place: fit is bought one rung at a time, and every rung has to justify what it adds to the cost of running the system for years, not months.

Standardising means adopting the platform’s way of running a process instead of reproducing your own. For most ledger work, routine purchasing, goods receipts, expense claims and ordinary invoicing, the standard process is not a compromise; it is often a cleaner version of what the business was already trying to do.

The test is simple to state and harder to apply honestly: would a customer, a supplier or an investor notice if this process worked the way the software expects? If not, the current process is a habit rather than an advantage. Habits deserve respect — people built them for reasons — but they rarely deserve custom code.

This is the rung where most value is left on the table, because it asks people rather than software to change. The approval three managers sign by email, the spreadsheet column that exists because of a customer who left years ago, the numbering scheme only one person understands: each can become a formal requirement if nobody questions it, and each requirement pushes the project one rung higher.

What standardising does not mean

It does not mean forcing the business into a process that damages a real commitment. If the way you schedule deliveries is why distributors stay with you, or the way you quote is why you win work others lose, that process is a differentiator and belongs further up the ladder. The discipline lies in being strict about which processes earn that status — usually far fewer than the first workshop suggests.

Nor does it mean accepting a poor process because the software happens to ship with it. Standard is the default, not a verdict. A standard flow that creates rework in your context is a gap to record, and the fit-gap work described later is where it gets weighed properly.

Configuration shapes Odoo without changing its code: selecting and combining apps; setting company rules, taxes, warehouses, approval steps, user rights, document layouts and reports; and, where the edition includes Studio, adding fields, views, automation rules and simple models. For a business whose processes are largely standard with local variations, configuration is where most of the fit comes from.

Its strength is that it stays inside the platform. The system is still recognisably Odoo, so Odoo’s documentation applies, other partners can understand it, and staff who have used Odoo elsewhere can find their way around. That portability is easy to undervalue until the day the original implementer is no longer available.

Where configuration runs out

Configuration begins to strain in predictable places:

• a rule that depends on data from several apps at once and must be enforced, not merely reported;
• a document or record with no natural home in any standard app;
• a workflow whose states and transitions differ materially from what the app assumes;
• an integration that needs to exchange data in a way no available connector supports;
• screens for people — a supervisor on the floor, a driver, a field technician — whose working day looks nothing like that of the office user the app was designed around.

When a requirement meets one of those limits, the honest move is to record it as a gap rather than stretch configuration until it holds by accident. Automation rules stacked on automation rules, fields used for purposes their names no longer describe, and reports that quietly compensate for a missing workflow all show a process that has already moved to the next rung without anybody deciding it should.

Configuration still needs governance

No-code does not mean no consequence. A field added in a hurry becomes something reports depend on; an automation written by one administrator becomes behaviour the next cannot explain. Keep a register of configuration changes — what changed, why, who made the change and which process it serves — and retest the important ones whenever the platform moves to a new version.

Extending means adding code to Odoo: custom modules that introduce new records, workflows, rules or screens, and integrations that exchange data with systems Odoo does not connect to as standard. It is the right step when a few workflows sit outside what Odoo covers but the core of the business still fits the platform well.

A well-designed extension adds to Odoo rather than rewriting it. It introduces the record the business needs — a job, an inspection, a service contract with unusual terms — and ties it to the standard records around it, so sales orders, stock movements and invoices still behave as Odoo expects. Extensions that alter core behaviour are possible, but they are the ones that cost most at every upgrade.

Two practical constraints follow. Custom modules need Odoo.sh or an on-premise installation, because Odoo Online is limited to standard apps. And every custom module becomes code the business owns in all but name: the platform keeps evolving underneath it, and somebody has to keep it working.

Good candidates for extension

• a specialised approval or pricing rule the standard apps cannot express;
• an industry-specific record, such as material sent to a subcontractor for job work and received back;
• a connector to a logistics provider, marketplace, bank or government portal;
• a focused interface for a role that needs only a narrow slice of the system.

The line extension should not cross

An extension has become a rebuild when custom modules hold most of the business logic and Odoo is left supplying a login, a database and a set of apps nobody uses as designed. At that point the business carries the upgrade obligations of a platform and the maintenance obligations of a custom system at the same time, without the full benefit of either. Watching for that line, and naming it when it is crossed, is among the most useful things an implementation partner can do.

A custom build is justified when core processes, integrations, data or ownership needs genuinely outgrow what configuration and extension can hold, and the business can fund and run the result for its whole life. Both halves carry weight. A strong case on fit with no capacity to own the outcome is not a case for building.

The strongest signals tend to arrive together:

• the operation that makes the business distinctive is also the one no platform models well;
• the data model is fundamentally different from the one the platform assumes, not merely larger;
• integrations are so central that the ERP is really the coordinator of several other systems;
• the business wants full control of the roadmap, the code and where the system runs, for reasons it can state plainly;
• there is, or will be, an internal or contracted team with the skills and budget to maintain it.

The weak signals deserve naming too. Frustration with a badly implemented ERP is a reason to implement better, not necessarily to build. A demonstration that did not match the business is often evidence of a poor demonstration. A wish to avoid licence fees overlooks that a custom system has running costs of its own. And “we are different” is true of every business and decisive for very few processes.

Custom does not have to mean everything

Even when building is right, it rarely needs to cover the whole business on day one. The version that tends to work starts with the operational spine — the job or order, its owner, its stages, its approvals and its history — and adds stock, procurement, invoicing and reporting once that spine is genuinely in use. Accounting in particular is usually better kept in a system built for it and connected, rather than rebuilt.

That is the shape of Branditify’s ERP and operations service: an operations system built around one shared record, with explicit handoffs, approvals inside the workflow and one current status every team reads. The same service page is plain that custom is not automatically the right answer, and that plenty of businesses are better served by configuring something that already exists.

The three paths differ in what they fit, what they change, how upgrades work, who owns the result and where each tends to go wrong. Configuration fits standard processes with local variations; extension fits a business with a few workflows Odoo does not cover; a custom build fits only core processes that no platform fits well.

Configure changes settings, fields, reports and the apps in use. Upgrades follow the platform’s release path, and ownership sits with the platform and its partner ecosystem. The risk to watch is bending the business to avoid any change at all — accepting a process that harms a real commitment because configuration was the comfortable answer.

Extend adds custom modules and integrations. Custom code must be tested on each upgrade, and ownership is shared between the platform and the code you commission. The risk is customisation that quietly becomes a rebuild, one reasonable module at a time.

Build custom changes the whole system, designed from scratch. Upgrades follow your own roadmap and release process, and ownership is entirely yours, maintenance included. The risk is building what a platform already does well — spending scarce engineering effort on ledgers, stock movements and user management that were never your advantage.

Read the map across its rows as well as down its columns. A process can sit comfortably in “configure” on fit and still belong in “extend” because of one integration; another can look like a custom candidate on fit and fail the ownership row because nobody will maintain it. The right column for a process is the one where every row is acceptable, not the one where a single row looks best.

The decision cannot be made well until the business knows how its work actually runs, so process mapping comes before any platform comparison. Teams that begin with demonstrations end up judging software against a process nobody has written down, which rewards the most persuasive presenter rather than the closest fit.

Map the work as it happens, not as the policy describes it

Follow real transactions end to end: an order from enquiry to cash, a purchase from requirement to payment, a production run from plan to dispatch, a return from complaint to credit note. For each step, record who acts, what they need to know, where that information lives today, what must be approved, what can go wrong and what happens when it does. The exceptions — the part shipment, the changed order, the rejected batch — reveal far more about fit than the smooth path.

Do this with the people who do the work as well as those who manage it. Supervisors, accounts staff and warehouse leads know which spreadsheet is really a workflow and which approval is really a phone call.

Separate differentiators from standard work

Once the map exists, mark every process as one of two kinds. Standard work is necessary but does not distinguish the business: the ledger, payroll inputs, routine purchasing. Differentiating work is part of why customers choose you, or of how you earn money in a way competitors cannot easily copy. Expect a long list of the first and a short list of the second; a long second list usually means the label is being applied too generously.

Run the fit-gap analysis

A fit-gap analysis compares each mapped requirement with what the candidate platform does in its standard and configured form. Each requirement is recorded as a fit, a gap configuration can close, a gap that needs extension, or a gap that would need a custom system — and, just as importantly, as a gap the business could close by changing how it works.

• Grade gaps by consequence, not by count. Twenty small report differences matter less than one missing control on an approval that commits money.
• Test gaps in a working database. A claim that something “can be configured” should be shown with your data and your exceptions.
• Record the decision and its owner. Every gap should end with a named choice: change the process, configure, extend, build or accept.

Only once gaps are graded does a pattern emerge. A handful of gaps, mostly configurable, point to Odoo. Gaps clustered in one area point to extension, or to a separate component for that area. Gaps spread across the core — the data model, the main workflow, the central integrations — are the first real evidence for a custom build.

Integrations often settle the path more decisively than features, because an ERP that cannot exchange data reliably with the systems a business keeps pushes the work straight back into spreadsheets. Frame each integration as a set of questions before choosing a platform, rather than assuming a connector exists because a brochure lists one.

For every system the ERP must talk to, ask:

• What does the other system expose — an API, scheduled exports, a database view, or nothing usable?
• Which side is the source of truth for each record, and what happens when the two disagree?
• Does data flow one way or both ways, and how soon does it need to arrive?
• What happens when the connection fails, and who finds out?
• Who maintains the integration when either system changes?

Accounting

If accounting runs inside the ERP, the question is whether the configured chart of accounts, taxes and reports suit your finance team and your advisers. If it stays in a separate system, the questions become which transactions move, at what level of detail, and how reconciliation works when a record is corrected on one side but not the other.

Ecommerce and marketplaces

Ask where orders, prices, stock availability and customer records are mastered, how returns and cancellations flow back, and what happens when an online order and a counter sale compete for the last unit. The answers differ sharply between a store run from the ERP itself and one run on a separate commerce platform.

Logistics and shipping

Ask which carriers or aggregators you rely on, whether labels, tracking and delivery status must come back into the order, and how failed deliveries and returns are recorded against the original sale.

Payroll and HR

Ask whether payroll runs inside the ERP, in a specialist payroll product or through an outside provider, and what the ERP actually needs back — often only costs posted to the right accounts and projects. Payroll depends heavily on local rules, so treat it as its own evaluation.

Our comparison of HRMS, HR portal and payroll software works through that choice in more depth, and it is worth reading before assuming payroll belongs inside the ERP at all.

E-invoicing and statutory reporting

Where e-invoicing or other statutory reporting applies to the business, ask how invoices are submitted and acknowledged, how cancellations and credit notes are handled, and who updates the integration when requirements change. Confirm what is supported for your country, edition and hosting option with the vendor and your advisers; a guide cannot tell you whether a particular set-up meets your obligations.

A long integration list does not, on its own, argue for custom. It argues for deciding early which system owns each record, and for costing every connector as a piece of work with maintenance attached.

The data model — the records a business keeps and how they relate — is the most durable decision in any ERP and the hardest to change later. If your core records map naturally onto a platform’s customers, products, orders, stock movements and invoices, its model is an asset. If they do not, every report, integration and workflow ends up translating between the business and the software.

Look hardest at the records that carry your differentiating work. A business selling configurable assemblies, managing equipment through rental cycles or running production through subcontractors may find those concepts supported, partly supported with extension, or foreign to the platform. The fit-gap analysis should test them specifically, with realistic volumes and awkward cases.

The question tends to arrive early for manufacturers and industrial companies, where bills of materials, operation sequences, job work and quality holds can make the production record the centre of the model rather than one module among many.

Migration is judgement, not a transfer

Data migration is never a clean copy, whichever path you take. The work that decides the outcome is the same on both sides:

1. List the sources. The old ERP, accounting, spreadsheets, shared drives, the supervisor’s notebook.
2. Sample before promising. Read a real slice of each source to learn what is actually in it.
3. Map fields and meanings. A column called “status” in three spreadsheets can mean three different things.
4. Clean. Duplicate customers, several spellings of one item, quantities recorded in mixed units.
5. Load in order. Master data first, then open transactions, then whatever history is worth carrying.
6. Verify against the source. Checked by people who know the data, not accepted because an import reported success.

Decide deliberately what history moves. Open orders, current stock, outstanding balances and active master data usually must. Closed transactions from years ago are often better summarised, or left readable in an archive, than carried into a new system as records nobody fully trusts.

Migration also exposes a real difference between the paths. With Odoo the target structure already exists, so the work is shaping your data to fit it. A custom build lets you shape the structure to your data, but you design the importers, the validation and the reconciliation yourself.

Upgrades are where the difference between configuring, extending and building turns from a one-off decision into a recurring cost. Odoo releases new major versions and supports each one for a limited period, and databases hosted by Odoo are expected to stay on supported versions, so a business on the platform should plan for upgrades as a normal part of owning it.

Odoo describes the upgrade as a sequence: request the upgrade, receive an upgraded test database, test the business on it, then upgrade production. The testing step is where the real work sits. A mostly configured system needs its key processes, reports and automations checked on the new version. An extended system needs its custom modules adapted and retested as well — and whether any part of that is covered by Odoo’s own upgrade service depends on the terms that apply to you, so confirm it rather than assume it.

Self-hosted installations have more say over timing, but postponing upgrades has a price of its own. The wider the gap between versions, the harder the eventual move, and the more custom code has to be revisited in one go.

How to keep extensions upgradeable

• Prefer adding new behaviour to overriding standard behaviour.
• Keep custom modules small, single-purpose and documented.
• Hold the source code under version control, with automated tests for the business rules that matter.
• Review every customisation before each upgrade, and retire what the new version now does as standard.

Upgrades in a custom system

A custom ERP has no vendor release to follow, but it is never frozen. Its frameworks, libraries, databases and hosting all move, and the business changes faster than any of them. In place of a platform’s release path it needs its own roadmap and release process: somebody deciding what changes, testing it and deploying it without disrupting the operation. That discipline must be funded as a standing activity, not rediscovered when something breaks.

Every ERP needs two kinds of ownership — someone to implement it and someone inside the business to own it afterwards — and most troubled ERPs have the first without the second.

Implementation partners

Odoo implementations are delivered by Odoo’s own services or by partners in its ecosystem, who map processes, configure apps, write custom modules, and run migration and training. A good partner earns its fee by challenging requirements rather than accepting all of them; the strongest implementation often contains less customisation than the business first asked for.

For a custom build, the partner is a software team, and the questions change: how will the system be architected, documented, tested and handed over, and what happens if the business later wants a different team to take it on?

Anyone budgeting for that team should also look at what custom software development costs in India, because the drivers that set the cost of any custom system are the same ones that decide the size of an ERP build.

Internal administration

Whichever path is chosen, the business needs people who understand both the process and the system. On a configured Odoo that means a trained administrator who manages users and access, keeps configuration tidy, answers first-line questions and knows when to call the partner. An extended system adds someone who can specify changes precisely and accept them properly. A custom ERP needs a product owner with authority over the roadmap and a technical team, internal or contracted, responsible for keeping it running.

• A process owner for each major area, who decides how the work should run.
• A system owner, who decides what changes in the software and in what order.
• Documented access and permissions, reviewed whenever people join, move or leave.
• A change log covering configuration and code, so the next person can understand the last decision.

Implementation capacity matters just as much before go-live. An ERP project leans heavily on the people who know the business best, at the very moment they are still running it. If those people cannot be released for mapping, testing and training, no choice of platform will rescue the project.

A hybrid keeps Odoo, or another platform, as the system of record for standard work and builds custom software only where a different shape adds real value. For many businesses it is the most sensible place to land, because it confines custom ownership to the areas where it earns its keep.

Common hybrid patterns include:

• A custom customer or dealer portal that reads orders, invoices and delivery status from the ERP and presents them in a way designed for that audience.
• A focused floor or field application for supervisors, technicians or drivers, writing back to the ERP only what it needs.
• A specialist system for the differentiating process — a configurator, a scheduling engine, a job-work tracker — integrated with the ERP for stock, purchasing and accounting.
• A reporting layer that combines ERP data with sources the ERP does not hold.

Manufacturing shows the pattern clearly. Finance and purchasing can stay in an established system while a manufacturing-first system for the production floor carries production orders, work orders, job cards, holds and completion. That is the arrangement Branditify’s Manufacturing ERP page describes, with connections to accounting, stock and equipment scoped per project against what the existing systems can genuinely expose.

Stock can be separated in the same way when its states are complex enough to justify a dedicated inventory management system beside the ERP, reading and writing only the movements production and sales depend on.

Supplier work follows the same logic. Where quotes, approvals and purchase orders are the source of friction, a separate vendor and procurement workflow can own that lifecycle and hand receipts to the rest of the business.

Hybrids carry costs of their own. Every boundary is an integration to design, test and maintain, and each record needs a clear owner so that the portal, the app and the ERP never disagree about the same order. The architecture is only as sound as its decisions about which system is the source of truth.

The reasoning reaches beyond ERP. The build-or-buy question applied to CRM, where Zoho, HubSpot and Salesforce play the part Odoo plays here, resolves along the same lines: a standard core, with custom work reserved for the edges that genuinely differ.

The fair comparison is the total cost of owning a system over its life, not the cost of getting it live. Both paths carry broadly the same categories; what differs is who carries each one and how predictable it is.

On an Odoo-based system

• subscription or licence costs, depending on edition, apps, users and plan;
• hosting, whether with Odoo or on infrastructure you manage;
• implementation: process mapping, configuration, testing and training;
• custom module and integration development;
• data migration and cleansing;
• upgrade projects, including retesting configuration and adapting custom code;
• partner support and continuing change requests;
• internal administration, and the time key staff give to the system.

On a custom ERP

• discovery, design and the initial build;
• integrations and data migration;
• infrastructure, monitoring, backups and security;
• maintenance of frameworks, libraries and dependencies;
• continuing development as the business changes;
• documentation, knowledge transfer and the cost of replacing people who understand the code;
• product ownership and internal administration;
• the opportunity cost of engineering effort spent on standard functions.

Two categories are routinely underestimated on both sides: the time the business’s own people spend on the project, and the cost of change after go-live. A configured platform tends to make change cheaper for standard processes and dearer for unusual ones; a custom system tends to do the reverse. Neither path offers a free year after launch.

Where Branditify’s own services or systems form part of a comparison, their published starting points sit on the pricing page rather than in this guide, and they are not an estimate for a custom ERP. A real figure for either path comes only from scoping the processes involved.

Both paths fail in recognisable ways, and the failures mirror each other: an over-customised Odoo becomes an expensive custom system in disguise, and an underfunded custom build becomes a platform nobody maintains.

The over-customised Odoo

It usually begins with reasonable requests: a field here, an override there, a module to reproduce a report from the old system. Each change is small, and nobody owns the total. A few versions later, the business finds that upgrades have become major projects, that only one partner understands the code, and that improvements in newer versions cannot be adopted because custom modules replaced the areas they touch.

• customisations that preserve old habits rather than real differentiators;
• overrides of standard behaviour where an addition would have served;
• no tests, no documentation and no register of what changed and why;
• upgrades deferred until the gap is too wide to cross comfortably.

The underfunded custom build

This one begins with a strong case and a budget sized for the first release alone. The system launches, the team that built it moves on, and requests queue with nobody to handle them. Security updates slip. The one developer who understood the data model leaves. Teams start working around the system in spreadsheets, and a few years later the business is evaluating platforms again — this time with a migration out of its own software.

• no product owner with authority over what changes;
• a first release that tries to cover every department;
• standard functions — accounting, user management, document generation — rebuilt without need;
• no funding line for maintenance after launch;
• code, hosting or documentation the business does not fully control.

The quieter failure: bending the business

A third failure rarely gets named. A business so determined to avoid customisation that it accepts a process damaging a real commitment — a delivery promise, a quality check, a pricing structure — has saved money on software and spent it on its customers’ patience. Standardisation is the first rung because it is usually right, not because it is always right.

A fair evaluation tests every path against the same mapped processes, the same data and the same ownership assumptions, so that neither Odoo nor a custom build wins by being described more generously. The sequence below keeps it even-handed.

1. Write down the processes and differentiators first. Agree them internally before any vendor or partner is involved.
2. Define the scenarios. Choose the transactions that matter, exceptions included, and use them for every option.
3. Run a fit-gap on the platform. In a working database, with your data, graded by consequence.
4. Scope the custom alternative honestly. Include integrations, migration, hosting, maintenance and the team that will own it.
5. Consider the hybrid explicitly. Ask which processes would sit on the platform and which, if any, deserve their own system.
6. Compare total cost of ownership by category. Over the life you expect to run the system, not just to go-live.
7. Test the ownership plan. Name who will administer, change and upgrade the system under each option.
8. Decide per process, then check the whole. Make sure the combined architecture is one the business can actually run.

Be wary of any evaluation whose answer was settled before the processes were mapped. A partner that implements only one platform and a development firm that only builds are each inclined to see their own answer in your requirements. That is not dishonesty; it is what expertise looks like from the inside. The remedy is evidence from your own scenarios.

Questions for an Odoo implementation partner

• Which of our requirements would you advise us to meet by changing our process rather than customising?
• Which edition and hosting option does your proposal assume, and what does that rule in or out?
• What will be configuration, what will be Studio, and what will be custom code?
• How do you design custom modules so upgrades stay manageable, and how are they tested?
• Who owns the custom code, and where is it kept?
• What will our internal administrator need to know, and how will they learn it?

Questions for a custom ERP team

• Which of our processes would a platform handle well, and why build them anyway?
• How will the data model absorb change we cannot foresee today?
• What do we receive at handover — code, deployment access, documentation — and could another team take it on?
• What does maintenance involve after launch, and how is it resourced?
• How will accounting, payroll and other specialist systems be connected rather than rebuilt?
• What would a narrow first release look like, and what would it teach us?

Questions for both

• How will you confirm what each existing system can expose before designing integrations around it?
• How will migration be sampled, cleaned and verified?
• What would make you recommend the other path?

The last question is the most revealing. A partner that can describe, specifically, when you should not choose them is a partner whose recommendation carries weight.

The decision is rarely “Odoo or custom” for the whole business. It is a set of process-level choices — standardise here, configure there, extend where a real gap exists, build only where nothing else carries the work — assembled into an architecture the business can fund and operate.

Start with Odoo when your processes are largely standard and configuration or extension can cover the differences. Consider a hybrid when one or two differentiating processes need a shape of their own. Build a custom ERP only when core processes, integrations, data or ownership needs genuinely outgrow configuration and extension, and the business is prepared to own the system for its whole life.

Whichever path you take, the same habits decide the outcome: map the work before choosing software, be strict about what counts as a differentiator, treat every customisation as a commitment, name the people who will own the system, and budget for the years after launch as seriously as the months before it.