Custom development only where standard Odoo falls short
Diego first checks whether configuration or integrating another system is enough. When coding is needed, the work goes into a separate module with its automated test, and the code stays in your company's name so any provider can take it over.
Development on Odoo 17, 18, 19 and 20, or on your current system if it has an API
What stays in your name at closing
- Code repositoryIn your company's name
- Odoo base systemLeft untouched
- Automated testOne for each delivered flow
- Screen designApproved before any coding
- Version upgradeTested in a test environment
A change made inside the base system is paid for at every upgrade
The same requirement can be built in two ways. The difference shows months later, when a new Odoo version comes out or when the person maintaining it changes.
Change inside the base system
- Every version upgrade breaks something and gets postponed
- Nobody knows exactly what was changed or why
- Only the person who coded it can touch it
Separate module, in your company's name
- The module is migrated and tested before going to production
- Every change is in the history, with date and reason
- Another provider continues it with the manual and the tests
What staying this way costs
Daily workarounds on screens that do not answer the question
Seeing a balance means opening five screens or exporting to Excel. The phone shows the desktop view shrunk down.
An Odoo version that cannot be upgraded
Changes made inside the base code block the migration. The company misses the improvements of newer versions.
A provider you cannot leave
Without a repository, documentation or tests, changing provider means rebuilding the development.
Diego codes only what the diagnosis justifies
DMG-RT, Diego's own method, ties each development to an indicator measured before touching the system; in this service, the time the task takes on screen and how often people leave the system to do it.
Diagnosis: walking the screen with the person who uses it
Diego counts today's workarounds: screens opened, exports to Excel, time per lookup. Then he checks whether standard Odoo solves it with a setting, another module or an integration. Coding is the last option on the list.
Deliverable: Findings letter with the shortest option for each need and the indicator baseline.
Design: the screen is approved before any code is written
Sketch for desktop and phone, business rules and test plan. The process owner approves it. That design sets the fee for each delivery.
Deliverable: Approved design, indicator sheet and budget per delivery.
Implementation and control: two-week deliveries
Each delivery is coded in a separate module and tested in an environment with a copy of your data. An automated test runs the whole flow before every change. It goes to production after a backup, and Diego verifies it on your real instance, on desktop and phone.
Deliverable: Module in operation, one automated test per flow and change history.
Handover: the code stays in your repository
Repository, credentials and documentation pass to your company. Your team receives a manual per role. Reviews at 3, 6 and 12 months measure the same baseline indicator.
Deliverable: Closing record, operating manual and technical documentation.
- 1. Configure what Odoo already offers
- 2. Integrate another module or system
- 3. Code in a separate module
- 4. Hand over code and tests in your name
What you receive lets you change provider without rebuilding the development
The usual objection is being tied to whoever wrote the code. That is why every need goes through the standard first, and whatever does get coded arrives with repository, design, tests and manual in your company's name.
| Need | What the standard offers | Decision |
|---|---|---|
| Approve purchases by amount | Double validation in Purchase | Configure |
| An extra field on the sales order | Custom field with Studio | Configure |
| Sell online with the same warehouse stock | Odoo eCommerce module | Configure |
| Orders from a marketplace or payment gateway | Connector or API between both systems | Integrate |
| Budget balance with an alert, in a single view | No standard view brings it together | Code |
| Phone screen for the technician, with the steps of your trade | Field Service covers the order, not your own steps | Code |
| Commission or rate calculation specific to your trade | Standard rules cannot express it | Code |
Repository with the full history
Hosted on your company's account. Every change has an author, a date and a reason.
Approved design document
Desktop and phone sketches, business rules and the scope of each delivery.
Automated tests
One per flow. They run before every change and before every version upgrade.
Manual per role and technical documentation
For the user, for the administrator and for the next developer.
Credentials and access
All in your company's name. Diego keeps no access you have not authorised.
Walk-through the automated test repeats
- Create the order with a test customer
- Approve according to amount and owner
- Deliver from the right warehouse
- Invoice and check the journal entry
- Repeat on the phone view
Illustrative example. If a step fails, the change does not go to production.
Bring the screen you are missing and review with Diego whether to configure, integrate or code.
Book a 30-min diagnosisWhat Diego needs to start and when coding is not a fit
You provide
- A person who uses the screen every day and can show how they work today.
- Access to a test environment with a copy of your data.
- A process owner who approves the design and each delivery.
- Your company's account where the repository will live.
When it is not a fit
If a setting or a standard module solves the need, Diego says so in the diagnosis and nothing is coded. If the process is not yet defined, it is better to sort it out first. If what is missing is two systems talking to each other, that is an integration.
Diego writes the design before the code
Diego Muñoz is a process and systems consultant who codes on Odoo from version 17 to 20. Before developing, he walks through the task with the person who does it and looks for the answer in the standard. When he codes, he does it in a module that belongs to the client, never in the base system or in third-party modules.
He does not consider a delivery finished until he sees it working on the client's real instance, on desktop and phone, with its automated test passing.
- Odoo 17, 18, 19 and 20
- DMG-RT method
- Enterprise architecture with TOGAF
Ownership, versions and cost of a development
Is the code mine?
Yes. The repository is created on your company's account, with the change history, the documentation and the automated tests.
What happens when I upgrade Odoo?
The module is migrated to the new version and tested in a test environment with the same automated tests before going to production.
Can I change provider later?
Yes. With the repository, the design document, the manual and the tests, another developer can continue the work without rebuilding it.
Do you work on systems other than Odoo?
Yes, if the system has an API or an accessible database. It is confirmed in the diagnosis, with your specific case.
Do you build phone apps?
Yes. The usual answer is an Odoo screen designed for the phone. When the case calls for it, an Android app connected to the ERP, with per-user access.
How is a development quoted?
With a fixed fee per delivery, after the design is approved. Each delivery has its scope and its test, and when it closes you decide whether to continue.
Review with Diego in 30 minutes whether your case calls for configuring, integrating or coding
- You show the screen or task that forces workarounds today.
- Diego checks whether standard Odoo solves it or coding is needed.
- You receive the shortest option and its scope in writing.