Plemo pauses every Odoo customization at the same place: a written spec that waits for your approval before any development starts. Some customers read that document in twenty seconds and click approve. They are usually the ones surprised by what turns up in the sandbox a while later.
The spec is the cheapest place in the entire process to be wrong. Fixing a sentence costs you a minute of reading. Fixing built code costs a development cycle, a fresh sandbox, and another review. The few minutes you spend reading the spec properly are the highest-leverage minutes in the whole request.
Read it as behavior, not as a screen
The most common way a spec goes wrong is that it describes what a screen will look like without saying what the system will do. "A new field for delivery priority on the sales order" is a layout note. It does not tell you whether the priority copies to the delivery order, whether it is required, whether it can still be edited after confirmation, or what happens to the sales orders already sitting in your database.
So read every line and ask what happens next. If the answer is not in the document, that gap gets resolved by whoever writes the code, and their guess can be perfectly reasonable without being what you wanted.
Check the boundary, not just the change
A good spec says what it does not touch. Odoo modules are connected in ways that are not obvious from the screen in front of you: a change to how a sales order is confirmed can reach inventory, invoicing, and your reporting. If the spec is silent on those edges, that is the question to ask before approving.
Two boundaries are worth naming explicitly:
- Existing records. Does the change apply only to new documents, or is it applied backwards to what is already in the database? Both are legitimate answers. Silence is not.
- Standard behavior. Is the change adding something alongside Odoo's standard flow, or replacing part of it? Replacing costs more over time, because every future Odoo version has to be reconciled with it.
Check who, and when
Specs describe features and forget people. If a new field, button, or approval step is being added, the spec should say which user groups see it and which ones can change it. In practice this is where most post-launch complaints come from: not that the feature was wrong, but that the wrong role could use it, or the right role could not find it.
The same applies to timing. If a step is meant to block something, say what it blocks and at which state. "Approval required before invoicing" and "approval required before delivery" are one word apart in a sentence and very far apart in a warehouse.
Push back when the spec is broader than your problem
The chat flow that produces the spec asks clarifying questions, and it narrows requests that are too broad to build safely. That narrowing works in the other direction too. If you asked for a small fix and the spec that came back reshapes an entire process, say so. A large spec is not a bonus. It is more surface area to test, more to explain to your team, and more to carry into your next Odoo upgrade.
The honest version of the trade-off: a customization is a long-lived commitment, and the smallest change that solves your actual problem is almost always the right one. If configuration alone gets you there, that beats any custom code, however cleanly it is written.
What approval actually starts
Approving the spec is not approving the result. Development runs against the approved document, and the output lands in a sandbox: a preview environment separate from your live system, where you check the behavior against your own data before anything reaches production. Nothing is deployed to your live Odoo on the strength of the spec alone.
That is worth knowing because it changes how you read the document. You are not making a final decision about your production system. You are agreeing on what should be built, so the sandbox review has something to be measured against. A vague spec makes the sandbox review vague too, because there is no agreed answer to compare the preview with.
A short checklist
- Does every new field or step say what it affects downstream?
- Does it say what happens to records that already exist?
- Does it name the user groups involved?
- Does it say what it deliberately leaves alone?
- Is it the smallest version of the change that solves your problem?
- Could you hand it to a colleague who was not in the conversation, and would they read it the way you do?
If that last one fails, send it back. Rewriting a spec is free.
Plemo's customization flow, credit model, and plans are at plemo.ai. When a change is large enough to need design work and a consultant in the room rather than a spec and a sandbox, that is our custom development service.