Odoo, changed to fit the way you already work
Standard Odoo is built for a generic business and yours is not one. We change the fields, the screens, the approvals and the documents until the system matches the way you work. We do that in Studio and in code, which is what lets us pick whichever one your change actually needs.
- Quotation
- Quotation Sent
- Sales Order
S04417
- Order Lines
- Other Info
- Notes
The screen your team already knows, doing what your business needs.
What we change
Fields and screens
Fields that calculate, columns that matter to you, and screens laid out in the order your team actually works through them.
Approvals and workflow
Who signs off what, at which value, and what happens when they do not. Stages, gates and the rules sitting behind them.
Automation
Rules that fire when something changes: a stage moves, an email goes out, a task is created, a figure is recalculated, without anyone having to remember.
Document layouts
Invoices, quotations, delivery notes and statements laid out the way your business issues them, carrying your terms and your fields.
Views and reporting
List, kanban, pivot and graph views set up to answer the questions your managers actually ask, rather than the ones Odoo ships with.
Access and visibility
Who sees which records, which fields are read only to whom, and what each role lands on when they log in.
We work in both Odoo Studio and custom code
| Studio Changes made in Odoo’s own interface, without writing code. | A module Written by our developers in Python, XML and OWL, and kept in version control. | |
|---|---|---|
| Comes with | Odoo’s Custom plan. On the Standard plan, installing Studio moves you to Custom when your next bill is generated. On Community it is not available at all. | Nothing. It runs on Community and on Enterprise, and it does not move you between plans. |
| Where it ends up | Odoo puts everything Studio creates into a single module in your database, named studio_customization. | A repository that belongs to you, with the full history of every change in it. |
| Moving it | That module exports as a file and imports into another database running the same version with the same apps installed. | Installed on any database on a compatible version, and carried forward when you upgrade. |
| Good for | Fields, views, report layouts and straightforward automation rules. | Anything with real business logic, anything a department will come to depend on, anything that has to survive several versions. |
| The catch | One module holds every change you have ever made, so no single change can be upgraded, switched off or removed on its own. | A small change costs more up front than clicking it together in an afternoon. |
Changed for clients
Needs confirmation
The same three implementation projects stood here as placeholders. A card on this page has to be one change, named: the screen, the field, the approval or the document that did not fit, and what we did to it. A whole rollout does not evidence that.
Each card needs
- The client, or a descriptor we can use instead if the name is confidential
- What no standard Odoo app covered
- What we changed
- Which Odoo apps it works alongside
- The outcome, only where it can be verified
Worth asking about first
- Which client has a field or a screen we added in Studio that we can name, and what were they tracking outside Odoo before it?
- Which invoice, quotation or certificate layout have we rebuilt, and what did the standard Odoo one get wrong for them?
- Which approval chain have we put in, and what was the manual step it replaced?
- Any change where we recommended Studio over a module, or the other way round, and the reason. That is the page’s whole argument, and one named example carries it further than the comparison panel does.
Common questions
Will our Studio changes survive an upgrade?
Odoo keeps everything Studio creates in one module in your database, called studio_customization, so the changes are not loose records and they are not lost. The difficulty is that it is a single module holding every change you have made, which means they can only be reviewed, tested and fixed as one lump rather than one at a time. On a small set of changes that is fine. On a few years of accumulated ones it is the reason an upgrade turns into a project. We will tell you which of your changes are worth moving into modules of their own before that happens.
Can our own team make changes afterwards?
For Studio changes, yes, and we would rather you could. We will show your administrators what is safe to change themselves and what is not, because a field you can add without calling us is cheaper for both of us. Module changes need a developer, which is the trade you make for logic that is tested and version controlled.
Do we need Odoo Enterprise for this?
For Studio, yes. Odoo includes it in the Custom plan, and if you are on the Standard plan, installing it moves you to Custom at your next bill. That is a real cost and you should know about it before anyone clicks install. On Community there is no Studio, so the same changes are made in modules instead, which is a perfectly normal way to work and is how a large part of the Odoo world operates.
Someone else made Studio changes we do not understand. Can you take them on?
Yes, and it is a common place to start. We go through what is in studio_customization, write down what each change was meant to do, tell you which ones are safe to leave and which are going to cause you trouble at the next version, and move the ones that matter into proper modules. You get a document at the end that says what your system actually does, which is usually the thing nobody has.
How do you quote customization work?
We quote against a written specification that says what will change, which screens and records it touches, and what it deliberately will not do. For Studio work that is usually quick. For anything that needs a module we will say so at that point, with the difference in cost, so the decision is yours and not a surprise on an invoice.
What if a change turns out to need a module after all?
We tell you before we start, not halfway through. Part of the scoping work is deciding which side of that line each change falls on, and we would rather lose a small Studio job than deliver something in Studio that we know will fail you in two years. If we get that call wrong, it is on us to put right.
Other Odoo services
Build
Get Odoo in place and shaped to your business
Tell us what Odoo gets wrong for you
Describe the screen, the step or the document that does not fit. We will tell you whether it is a Studio change, a module, or something you are better off not doing, and we have no reason to steer you either way.