We are working with a client in the United States that manufactures... things.
I cannot be more specific without risking a lawsuit, so let's leave it there: they are very good at manufacturing things. Our job is to customize Odoo so their process fits inside a system they can actually use.
This is where the conversation gets interesting.
There is an old line in custom software: if the client's process is very specific, you should build everything from scratch.
It sounds serious. It sounds artisanal. It sounds expensive.
After more than fifteen years walking both roads, my very modest opinion is that this line is often a billing strategy dressed as architecture.
Because when people say “from scratch,” they almost never mean from scratch.
They still need users, permissions, products, inventory, sales orders, invoices, documents, logs, imports, exports, backups, search, filters, notifications, roles, reports, API access, audit trails, and some way to explain to the next developer why the thing works the way it works.
So the team spends months rebuilding a large part of what someone already built. Then, after all that, they finally reach the small part that makes the client different.
Small does not mean unimportant. It means the opposite. It means you should protect your time for that part.
For this project we are starting with Odoo 19 Enterprise. Not because Odoo is perfect. Odoo is not perfect. Sometimes you have to fight it. Sometimes you have to read the source code. Sometimes a field is named in a way that suggests somebody in Belgium had a bad Monday.
But Odoo already has the boring machinery: sales, inventory, purchases, manufacturing, accounting, permissions, APIs, traceability. The smart work is not rebuilding that machinery. The smart work is understanding how this company works and adapting the system without breaking the parts that are already solved.
The first job is listening.
We use Granola to keep track of conversations with the client. Meetings become notes. Notes become action items. Action items become context for the agent. The agent then connects that with emails, attachments, decisions, previous tests, and the pieces of project memory already stored in SQLite.
A meeting ends. We identify the work. Then the loop starts:
- plan
- build
- correct
- test
- correct again
- document
- show something real at the next meeting
That is the job. It is less romantic than a greenfield rewrite and much more useful.
Clients change their mind. This is not a client bug.
Sometimes they change their mind because they understood their own process better after seeing it written down. Sometimes someone from operations says, “That is not how it happens in the warehouse.” Sometimes the spreadsheet everyone trusted turns out to be “the spreadsheet Pedro uses,” and of course Pedro keeps it updated in his own way.
Getting offended by this is a waste of energy.
The system has to absorb correction. The team has to absorb correction. The agent has to absorb correction.
That is why memory matters. The agent keeps track of the offline conversation too: the emails, the attached files, the questions that were answered, the questions still open, the last version of the decision. When the client changes direction, we do not start from zero. We explain what changed and how to prove the new version works.
So what do I do?
Look at how many times the word “correct” appears in this process.
That is my part.
Sometimes I correct the spec. Sometimes I correct the interpretation. Sometimes I tell the agent that technically it worked, but it proved nothing. A 200 OK is not a business test. Creating a sales order is not enough if the lines are wrong. An integration is not ready because it worked once. It is ready when it fails in a way we can understand, explain, and fix.
More and more, my job is not to write every line of code. My job is to direct the cycle: understand, decide, correct, demand evidence.
I like that part.
The real difference is not promising custom software as an excuse to burn money rebuilding modules. The real difference is knowing what not to build, what to reuse, what to adapt, and where to cut carefully.
Starting from zero sounds romantic.
For real companies, with real people and real operations that need to keep moving tomorrow, I prefer something else: a strong base, technical judgment, memory, tests, corrections, and no misplaced pride.
That scales better.