When the standard isn't enough, we build the missing piece
Standard Odoo covers a great deal out of the box. But eventually there's the one process no module handles, and that's exactly where we start: with our own modules that run alongside Odoo instead of against it, versioned and documented.
Signs standard Odoo isn't quite enough
Most businesses run fine on out-of-the-box Odoo for a while. These are the moments that usually start the conversation about custom development.
Workarounds instead of workflows
Your team exports to Excel to do what the system should really be doing natively, every single week.
A process no module quite fits
Manufacturing routing, an approval chain, or an industry rule that standard Odoo simply doesn't model.
Reports that take an afternoon
The numbers already live in Odoo, but getting them into one usable document still means manual copy-paste.
Growing pains from a rigid setup
What worked cleanly at ten people starts breaking down the moment you cross fifty, or open a second site.
What customization actually means, in practice
Odoo customization covers everything from adding a single field to writing a fully installable app: extending views, adding business logic, automating approvals, building reports, and connecting systems that don't talk to each other by default.
Six ways we extend what Odoo can do
Most engagements combine two or three of these, depending on how far standard configuration can take you before custom work is genuinely needed.
Custom Modules
Installable Python and XML apps that live alongside Odoo's own code, built to the same platform standards.
- New business objects & models
- Custom fields & computed logic
- Installable, versioned apps
Custom Modules for Automation & AI
We've already built six modules of our own, for recurring tasks and for putting AI to work inside Odoo.
- Recurring tasks automated
- Documents & data processed
- Connected to AI services
Reports & Dashboards
QWeb PDF reports and live dashboards built around the numbers your management team actually asks for.
- Branded PDF documents
- Spreadsheet & BI dashboards
- Scheduled report delivery
Workflow Automation
Approval chains, automated actions and state machines that enforce how work is genuinely supposed to move.
- Multi-step approval flows
- Automated notifications
- Server-side business rules
UI & Data Entry Screens
Views, kanban boards and role-based dashboards designed around how each team actually works day to day.
- Custom list & kanban views
- Role-based dashboards
- Simplified data entry screens
Integrations
Purpose-built connectors for the systems that don't have a ready-made Odoo integration already available.
- Webservices, REST & XML-RPC
- Sync over webhooks
- Bridges to legacy systems
Configure first, customize second, code only when we must
Every custom line of code is a small, permanent liability. It has to be tested against every future upgrade, understood by whoever supports it next, and maintained for as long as the business uses the system. So we default to the platform's own configuration first, and develop where it genuinely makes the difference. We work on the 80/20 rule: the standard covers most of what you need, and for the rest we decide together with you what's worth the effort and what isn't.
Does a standard feature already cover this?
Most "custom requests" turn out to be a built-in workflow nobody had configured yet.
Can the settings solve it?
Rules, approvals, sequences, pricing logic and permissions are settings, not development.
Does it need its own module?
Anything that needs new fields or views, we build as its own module: versioned, documented, and traceable at the next upgrade.
Only then, custom development
For the cases where it genuinely makes the difference, built to platform standards and fully documented.
Which category does your request fall into?
We make this call together with you on every request. It decides the effort, the maintenance, and who can change it later.
| Configuration | Extension | Custom Development | |
|---|---|---|---|
| What it covers | Rules, approvals, permissions, pricing logic, numbering sequences | Extra fields, views and reports as a small module | New workflows, custom objects, integrations, full applications |
| How it's built | Through Odoo's own settings | As its own, versioned module | As its own, versioned module, with its own data model |
| Who can change it later | Your own team, after a short walkthrough | Us, or any developer who can read the code | Us, or any developer who can read the code |
| At the next upgrade | Carries over as-is | Checked and adjusted if needed | Checked and adjusted if needed |
| Best fit for | Anything that needs no new fields | Small, clearly-scoped additions | Anything with real logic, external systems or scale |
Why we don't use click-together tools
Whatever gets clicked together in a tool like that lives in the database, not in version control. Nobody can see who changed it or when, nobody can review it beforehand, and at the next upgrade you only find out afterwards whether it survived. We build a module instead. It takes longer the first time, and never again after that.
Eight steps, the same every time
The same disciplined path for a single new field and for a full custom module, just scaled to the size of the request.
Requirements & Scoping
We document exactly what the business needs to happen, and why the current setup doesn't cover it.
Technical Design
A written approach covering data model, affected views, and how it fits with your existing customizations.
Configure or Develop
We record, on the file, whether this genuinely needs development or whether the settings are enough.
Development
Built in small, reviewable increments, following the conventions of Odoo and the OCA, entirely in version control.
Code Review
Every change is reviewed once more before staging, against a fixed checklist.
Staging Environment
Tested on a full copy of your real data, never in live operation.
Your Sign-Off
You and your team see the actual behavior and approve it before it goes live.
Handover
Delivered with documentation and source access. It's yours from day one.
Not sure if your request needs development?
Describe the process to us. We'll tell you which of the three categories it falls into, before anything is commissioned.
What we check before anything ships
The same discipline that keeps large open-source projects stable, applied to every module we write.
Official Odoo Partner and active in the OCA
OCA membership isn't a badge for show. It's why our code follows the same conventions the Odoo community relies on.
Official Odoo Partner
Verified in Odoo's official partner directory for implementation and development work.
OCA Member
An active contributor to the Odoo Community Association's shared, standards-based modules.
What we've already built ourselves
We've built six modules of our own, for automation and for putting AI to work in Odoo. On top of that there's our BMD export interface, which sends posting data and documents from Odoo straight to accounting. All of it is live, documented, and carried forward at every upgrade.
Development questions we hear on almost every call
Tell us what you need us to customize
We'll tell you honestly whether it's a configuration, a small extension, or real development, and what it costs.