Custom ERP · Odoo as framework
Build a custom ERP on Odoo, when no off-the-shelf one fits
For businesses whose core workflows have never existed in any ERP, and never will. We use Odoo as the framework, its Python ORM, modular architecture, and accounting core, and write the modules that are uniquely yours.
See what we buildSome 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 distinguish a framework build from a vanilla deployment.
Domain modeling
We model your business as objects, relations, and constraints in Odoo’s ORM before writing UI. The data model is the bedrock; everything else inherits from it.
Custom modules
Each unique workflow lands as its own installable module: clean dependency graph, isolated tests, can be lifted out or swapped later without uprooting the rest.
Workflow engines
Multi-step state machines, conditional routing, approval chains, scheduled jobs, with audit trails. Built on Odoo’s server actions and mail flows, not bolted on.
Security and ACLs
Per-record, per-field, per-action access. Record rules tied to your real org chart. Audit log of every read and write where regulation requires it.
Reports and dashboards
QWeb PDFs for documents, Spreadsheets for analytics, custom controllers for whatever the standard reporters can’t express. Numbers are live from Odoo, not exported.
Integrations and APIs
REST, JSON-RPC, webhooks, queued connectors, EDI bridges. Bi-directional, idempotent, with replayable logs when something downstream breaks.
When this is the right path, and when it isn’t
We refuse the wrong fit. The page is more useful that way.
Build a custom ERP on Odoo when
- Your core workflow doesn’t exist in any off-the-shelf ERP and your team has been holding it together in spreadsheets for years.
- You’ve outgrown a vertical-specific tool, but a generic Odoo install still leaves a third of the day-to-day in side systems.
- You want to own the source code and run the roadmap on your timetable, not a SaaS vendor’s.
- You expect to keep evolving the model for five years or more and need a framework, not a frozen product.
Stay with standard Odoo when
- You’re under 25 users and the gap from standard Odoo is small. One or two custom modules close it; that’s the Customization service, not this.
- You already have a niche tool with an open API. The rebuild rarely pays back, use Integration to connect it to Odoo instead.
- You’d be the only company on the version you’d ship on. Custom-ERP work needs a maintenance budget you’ll actually keep funding.
- Your real problem is process clarity, not software. A Consulting engagement before any code is the cheaper, more honest fix.
How a custom ERP build runs
Six phases, designed so you can stop at any boundary if the picture changes.
Discovery
Two to four weeks of workshops with the people who do the work. We map the workflows, name the parts that are vanilla-Odoo-fit, and isolate the parts that need custom modules. Output: an architecture document and a fixed-fee proposal.
Domain modeling
We translate your processes into Odoo objects, relations, and state machines. Reviewed by your domain experts before any UI work. Catching a modeling error here costs days; catching it after build costs weeks.
Module specification
Each custom module gets a one-page spec: data model, key flows, access matrix, integration points, test cases. Your sign-off on each spec is what unlocks build.
Iterative build
Two-week sprints, demo at the end of each, working software you can click through on a staging instance. Scope changes flow through written change orders, no hidden invoicing.
Hardening
Performance profiling, edge-case testing, security review, data-migration scripts. The boring two months that separate “it demos well” from “it runs the business at month-end.”
Rollout and handover
Phased go-live, hypercare for thirty to ninety days, training for your in-house power users, full documentation of every custom module. You can hire a developer to maintain it from day one if you choose.
What we promise about the code
The four habits that separate a custom ERP from a forked one.
Upgrade-safe inheritance
We extend Odoo, never fork it. XPath view inheritance, _inherit on models, properly scoped migration scripts. Odoo 19 to 20 is a project, not a rewrite.
Source-code ownership
You own every line of custom code from day one. Hosted in your GitHub or GitLab, BSL where it makes sense, MIT for the parts you might open-source later. No lock-in clause.
Test-backed delivery
Each custom module ships with unit tests covering its public surface, plus integration tests for the workflows that matter. The test suite runs in CI on every commit.
OCA-aligned style
We follow the Odoo Community Association coding conventions. Any OCA developer can read your code on day one, the hiring market for maintenance is broad rather than vendor-specific.
Patterns from real engagements
We haven’t shipped a from-scratch bespoke ERP for every client. What we have shipped is heavy customization on Odoo’s framework, the same techniques you’d use to build a bespoke ERP from day one. Two engagements that exercised the framework hardest:
SAP B1 to Odoo with custom MRP and quality flow
Migration off SAP Business One plus custom shop-floor modules, quality gates, and maintenance workflows. Demonstrates the modeling work a bespoke ERP build does for the Manufacturing, Quality, and Maintenance domains.
Read the case study →DIST · MULTI-WAREHOUSEFour distribution centers, barcode and stock logic
Multi-warehouse routing, custom barcode flows, live cycle counts, and EDI bridges to top-10 retailers on Odoo Inventory. Demonstrates the routing, ACL, and operations-engine plumbing a bespoke distribution ERP rests on.
Read the case study →Ready to scope a custom build?
Book a free 30-minute architecture call. We map the workflows that need custom modules versus what vanilla Odoo can already do, and tell you honestly which path fits.
Custom ERP on Odoo, frequently asked
01Why not just buy a vertical-specific ERP?
For most niches, vertical ERPs are the right answer, narrower scope, faster start, lower risk. The custom-on-Odoo path makes sense when the vertical tool either doesn’t cover your actual core process or has aged into a vendor lock you can’t escape. We’ll tell you which case you’re in during discovery, including saying “buy the vertical tool” when that’s the right call.
02Do we own the source code?
Yes, every line from day one. Code lives in your GitHub or GitLab organization, you control the license and the roadmap, you can hire any Odoo developer to maintain it. We don’t hold the keys; we don’t want to.
03What happens at Odoo’s next major upgrade?
This is the question every senior tech buyer asks first, and the question that separates a custom ERP from a forked one. We extend Odoo with inheritance (XPath view inheritance, _inherit on models, _inherits for delegated tables), never fork. Every custom module ships with a migration script checked in alongside the model code. Major-version upgrades are scoped projects (typically four to ten weeks for a substantial custom build), not rewrites, because the framework is doing the heavy lifting.
04How long does a realistic custom ERP build take?
Six to twelve months from discovery to first production go-live for a single business unit, twelve to twenty for multi-entity or multi-country rollouts. Discovery and domain modeling are eight to twelve weeks of that, more than you’d guess, because the modeling errors caught there save months later. Total budget typically lands between $80K and $400K, quote-only after discovery.
05When will you tell us not to build this?
Whenever the gap from standard Odoo is small enough that one to three custom modules close it (that’s our Customization service), or whenever you have a working niche tool with an open API we can integrate to instead, or whenever the real problem is process clarity rather than software. We’d rather lose the build and earn the trust than sell you something you don’t need.