Why not just buy a vertical-specific ERP?

For most niches, a vertical ERP really is the right answer: narrower scope, a faster start, lower risk. Going custom on Odoo makes sense once the vertical tool stops covering your actual core process, or once it’s aged into a vendor lock you can’t escape. We’ll tell you honestly which case applies during discovery, including saying "buy the vertical tool" when that’s the right call.

Do we own the source code?

Yes, every line, from day one. The code lives in your GitHub or GitLab organization, you control the license and the roadmap, and you can hire any Odoo developer to maintain it. We don’t hold the keys, and we don’t want to.

What happens at Odoo’s next major upgrade?

It’s the first question every senior tech buyer asks, and the one that separates a custom ERP from a forked one. We extend Odoo through inheritance, XPath view inheritance, _inherit on models, _inherits for delegated tables, and never fork it. Every custom module ships with a migration script checked in right alongside its model code. Because the framework carries the heavy lifting, major-version upgrades stay scoped projects rather than rewrites, typically four to ten weeks for a substantial custom build.

How long does a realistic custom ERP build take?

For a single business unit, expect six to twelve months from discovery to first production go-live; multi-entity or multi-country rollouts run twelve to twenty. Discovery and domain modeling alone take up eight to twelve weeks of that, more than most people expect, because the modeling errors it catches save months down the line. Total budget usually falls between $80K and $400K, and we quote only after discovery.

When will you tell us not to build this?

We’ll say so whenever the gap from standard Odoo is small enough for one to three custom modules to close it, that’s our Customization service, or whenever a working niche tool with an open API is already available for us to integrate instead, or whenever the real problem is process clarity rather than software. Losing the build and earning your trust beats selling you something you don’t need.

Custom ERP · Odoo as framework

When no off-the-shelf ERP fits, build a custom one on Odoo

For businesses whose core workflows have never lived inside any ERP and never will. We treat Odoo as the framework, drawing on its Python ORM, modular architecture, and accounting core, then write the modules that belong to you alone.

See what we build

Some businesses have processes that don’t exist in any off-the-shelf ERP. Instead of starting from a blank page, we use Odoo as the framework, its Python ORM, modular architecture, security model, and accounting close, and write the modules that are uniquely yours. You get a custom ERP without rebuilding the foundations Odoo has already hardened across millions of installs.

This approach isn’t for everyone. We recommend standard Odoo, or light customization, for the vast majority of SMBs. Read when a custom ERP is the right call before scoping an engagement.

What "Odoo as framework" actually means

Six capabilities that set a framework build apart from a vanilla deployment.

Domain modeling

Before we write any UI, we model your business as objects, relations, and constraints inside Odoo’s ORM. That data model is the bedrock; everything else inherits from it.

Custom modules

Every unique workflow gets its own installable module, with a clean dependency graph and isolated tests, so it can be lifted out or swapped later without disturbing anything else.

Workflow engines

Multi-step state machines, conditional routing, approval chains, and scheduled jobs, all with audit trails, built on Odoo’s server actions and mail flows rather than bolted on afterward.

Security and ACLs

Access controlled per record, per field, and per action, with record rules tied to your actual org chart, and an audit log of every read and write wherever regulation demands one.

Reports and dashboards

QWeb PDFs handle documents, Spreadsheets handle analytics, and custom controllers cover whatever the standard reporting tools can’t express, all pulling live numbers from Odoo rather than an export.

Integrations and APIs

REST, JSON-RPC, webhooks, queued connectors, and EDI bridges, all bi-directional and idempotent, with replayable logs for when something downstream breaks.

When this path makes sense, and when it doesn’t

We turn down the wrong fit, which makes this page more useful.

Build a custom ERP on Odoo when

No off-the-shelf ERP contains your core workflow, and your team has spent years holding it together with spreadsheets.
A vertical-specific tool has become too small for you, yet a generic Odoo install would still push a third of your daily work into side systems.
You want the source code in your own hands and a roadmap that runs on your timetable rather than a SaaS vendor’s.
You plan to keep evolving the model for five years or longer, which calls for a framework rather than a frozen product.

Stay with standard Odoo when

With fewer than 25 users, the gap from standard Odoo tends to stay small enough that one or two custom modules close it, and that’s our Customization service, not this one.
If you already have a niche tool with an open API, a rebuild rarely pays for itself, connecting it to Odoo through Integration is the better route.
Shipping this way would leave you as the only company running that version. Custom-ERP work needs a maintenance budget you’ll keep funding for real.
When the real problem is process clarity rather than software, a Consulting engagement before any code gets written is the cheaper, more honest fix.

How a custom ERP build unfolds

Six phases, structured so you can pause at any boundary if circumstances shift.

Step 01

Discovery

Two to four weeks of workshops with the people actually doing the work. We map the workflows, identify what fits vanilla Odoo, and isolate what will need custom modules, ending with an architecture document and a fixed-fee proposal.

Step 02

Domain modeling

We translate your processes into Odoo objects, relations, and state machines, and your domain experts review it before any UI work starts. A modeling error caught here costs days; the same error caught after the build costs weeks.

Step 03

Module specification

Every custom module gets a one-page spec covering its data model, key flows, access matrix, integration points, and test cases, and your sign-off on that spec is what unlocks the build.

Step 04

Iterative build

Two-week sprints, each ending in a demo of working software you can click through on a staging instance. Any scope change flows through a written change order, so there’s no hidden invoicing.

Step 05

Hardening

Performance profiling, edge-case testing, a security review, and data-migration scripts, the unglamorous two months that separate "it demos well" from "it runs the business at month-end."

Step 06

Rollout and handover

A phased go-live, thirty to ninety days of hypercare, training for your in-house power users, and full documentation for every custom module. From day one, you’re free to hire a developer to maintain it.

What we promise about the code

Four habits that separate a custom ERP from a forked one.

Upgrade-safe inheritance

We extend Odoo rather than fork it, through XPath view inheritance, _inherit on models, and properly scoped migration scripts. Moving from Odoo 19 to 20 becomes a project, not a rewrite.

Source-code ownership

Every line of custom code belongs to you starting day one, hosted in your GitHub or GitLab, licensed BSL where that fits and MIT for anything you might open-source down the road. There’s no lock-in clause anywhere.

Test-backed delivery

Unit tests covering its public surface ship with every custom module, along with integration tests for the workflows that matter most, and the whole suite runs in CI on every commit.

OCA-aligned style

We write to the Odoo Community Association’s coding conventions, so any OCA developer can read your code from day one and the maintenance hiring pool stays broad instead of locked to one vendor.

Patterns from real engagements

Not every client has needed a from-scratch bespoke ERP. What we have delivered repeatedly is heavy customization on Odoo’s framework, using the same techniques a bespoke build would use from day one. Here are the two engagements that pushed the framework hardest:

MFG · CUSTOM MODULES

SAP B1 to Odoo with custom MRP and quality flow

A migration off SAP Business One, paired with custom shop-floor modules, quality gates, and maintenance workflows, shows the kind of modeling work a bespoke ERP build does across the Manufacturing, Quality, and Maintenance domains.

Read the case study →DIST · MULTI-WAREHOUSE

Four distribution centers, barcode and stock logic

Multi-warehouse routing, custom barcode flows, live cycle counts, and EDI bridges to top-10 retailers, all built on Odoo Inventory, shows the routing, ACL, and operations-engine plumbing that a bespoke distribution ERP depends on.

Read the case study →

Ready to scope a custom build?

Book a free 30-minute architecture call, and we'll map which workflows need custom modules against what vanilla Odoo already handles, then tell you honestly which path fits.

Book a free architecture call

Custom ERP on Odoo, frequently asked

01
Why not just buy a vertical-specific ERP?
For most niches, a vertical ERP really is the right answer: narrower scope, a faster start, lower risk. Going custom on Odoo makes sense once the vertical tool stops covering your actual core process, or once it’s aged into a vendor lock you can’t escape. We’ll tell you honestly which case applies during discovery, including saying "buy the vertical tool" when that’s the right call.
02
Do we own the source code?
Yes, every line, from day one. The code lives in your GitHub or GitLab organization, you control the license and the roadmap, and you can hire any Odoo developer to maintain it. We don’t hold the keys, and we don’t want to.
03
What happens at Odoo’s next major upgrade?
It’s the first question every senior tech buyer asks, and the one that separates a custom ERP from a forked one. We extend Odoo through inheritance, XPath view inheritance, _inherit on models, _inherits for delegated tables, and never fork it. Every custom module ships with a migration script checked in right alongside its model code. Because the framework carries the heavy lifting, major-version upgrades stay scoped projects rather than rewrites, typically four to ten weeks for a substantial custom build.
04
How long does a realistic custom ERP build take?
For a single business unit, expect six to twelve months from discovery to first production go-live; multi-entity or multi-country rollouts run twelve to twenty. Discovery and domain modeling alone take up eight to twelve weeks of that, more than most people expect, because the modeling errors it catches save months down the line. Total budget usually falls between $80K and $400K, and we quote only after discovery.
05
When will you tell us not to build this?
We’ll say so whenever the gap from standard Odoo is small enough for one to three custom modules to close it, that’s our Customization service, or whenever a working niche tool with an open API is already available for us to integrate instead, or whenever the real problem is process clarity rather than software. Losing the build and earning your trust beats selling you something you don’t need.