When does a task need a module instead of a setting?

When the workflow does not exist in the box: its own states and rules, a document that has to look exactly the way your industry expects, an integration with a warehouse system, a marketplace or a bank that has no ready adapter. Half the tasks change shape at the first call, because the answer people bring is usually already a solution.

Will custom code survive the next Odoo upgrade?

It survives by staying out of the way: inheriting rather than patching, keeping its own data in its own fields, touching core behavior only where the core offers a hook. Carried over that way, the next version is work measured in hours rather than a rewrite.

Studio is quick until the upgrade. Clicked-together automations cannot be read as a diff, which is exactly why they are the expensive part later. A module has a git history, tests where they earn their place, and a person who can read it a year from now.

Who owns the code you write?

You do. The module lives in your repository, under your license, and any other engineer can pick it up - no lock-in and no lease on your own logic.

Services

Odoo module development: your process, written as code

A module for what Odoo does not do out of the box - built so that the next version upgrade is a few hours of work, not a rewrite.

What modules I write

A workflow with its own states and rules: approvals, production steps, service contracts - whatever your process has and the standard apps do not. Documents that look exactly the way your industry expects: invoices, delivery notes, certificates, labels.

Changes to Sales, Inventory, Accounting or the website, made by inheritance, so the standard app stays intact underneath.

How it survives upgrades

By staying out of the way: inheriting rather than patching, keeping its own data in its own fields, and touching core behavior only where the core offers a hook. Studio and clicked-together automations are the expensive part precisely because they cannot be read as a diff.

The result carries over to the next version as work measured in hours, not as a rewrite.

What you end up with

A module in your repository, with your license, that any other engineer can pick up - no lock-in, no lease on your own logic.

And an honest estimate of the border: some of what you want is a week, and some of it is a quarter. Which one it is becomes clear on the first call, not after the contract.

How the work goes

You describe what should be different on the day the work is finished - in your words, not in Odoo's. Half the tasks change shape right here, because the answer people bring is usually already a solution.
I write the architecture on one page: which models are touched, what is inherited rather than rebuilt, what stays untouched, and what happens to each override at the next version.
You read that page before anything is built. It costs an hour and it is the last cheap moment to change your mind - including changing it to "this is not worth building", which happens and is fine.
Implementation, with tests where they earn their place. The mechanical half of writing them is done with AI, which is why tests stopped competing with features for the estimate. Which cases deserve a test is still decided by hand.
Staging on a copy of your real database - not on demo data, which has no customers with two spaces in the name and no imports from 2019. You check the work on your own records.
Production, with a written deployment order and a rollback that has been tried rather than assumed. Then two weeks of polish: the small frictions only appear in daily use, and that pass is what makes the module get used instead of worked around.

Modules that already run

Some of what I write is published on the Odoo Apps Store - you can install it and read the code before we talk.

See the modules

Worth reading before you decide

Odoo development: from the estimate to production - the same order of work in full, including what the next version costs and the defects that only appear on a live site.
Forty websites in one Odoo instance - what custom work looks like at scale.
Partner or independent developer - who writes the code and on what terms.

Questions that come up before the first call

When does a task need a module instead of a setting?: When the workflow does not exist in the box: its own states and rules, a document that has to look exactly the way your industry expects, an integration with a warehouse system, a marketplace or a bank that has no ready adapter. Half the tasks change shape at the first call, because the answer people bring is usually already a solution.
Will custom code survive the next Odoo upgrade?: It survives by staying out of the way: inheriting rather than patching, keeping its own data in its own fields, touching core behavior only where the core offers a hook. Carried over that way, the next version is work measured in hours rather than a rewrite.
Studio or a module?: Studio is quick until the upgrade. Clicked-together automations cannot be read as a diff, which is exactly why they are the expensive part later. A module has a git history, tests where they earn their place, and a person who can read it a year from now.
Who owns the code you write?: You do. The module lives in your repository, under your license, and any other engineer can pick it up - no lock-in and no lease on your own logic.