25 August 2026 · TechSlideITS
How to specify a customisation so it gets built right
Most customisations that get rebuilt were not badly built. They were built exactly as described, and the description was missing the cases that mattered.
When a customisation comes back wrong, the instinct is that the developer misunderstood. Usually they built precisely what was described.
What was missing was not detail about the normal case. It was the cases nobody thought to mention, because in the business they are handled by judgement rather than by rule.
The five things a specification needs
1. What triggers it
Does it happen when a document is saved, submitted, approved, or on a schedule? Can it happen more than once for the same record, and what should the second time do?
Vague triggers produce logic that fires at the wrong moment, and the symptom looks like a bug when it is a specification gap.
2. The rule, with numbers
"Apply a discount for bulk orders" is not a rule. Bulk starting at what quantity, what discount, whether it applies to the whole order or the excess, and whether it stacks with other discounts.
Write it as a worked example with real figures. If you cannot produce a worked example, the rule is not yet decided — and that is a decision for you, not the developer.
3. The edge cases
Where most rework originates. For any rule, ask:
- What if the value is zero, or negative?
- What if the record is amended after the rule ran?
- What if it is cancelled?
- What if two conditions are true at once?
- What happens for records created before this existed?
The last one is routinely forgotten and produces confusing behaviour for months.
4. Who can do it, and who can see it
Permissions get treated as an afterthought and matter enormously — especially for anything touching salary, cost or margin. State which roles can trigger it, and which can see the output.
5. What happens when it fails
Every automation fails sometimes. Should it block the user, warn and continue, or record silently for later?
Silent failure is usually the worst choice and frequently the default, because nobody specified otherwise.
Acceptance criteria before, not after
Write down how you will test it, before it is built.
Three or four specific scenarios with expected outcomes. Agreeing those up front means acceptance is a check rather than a negotiation — and it forces the edge cases to surface while they are still cheap.
One customisation, one purpose
Requests tend to accumulate. A report becomes a report with an export, then a scheduled email, then a filter.
Each addition compounds the testing and delays everything. Specifying one thing, accepting it, then specifying the next is slower on paper and faster in practice — and gives you something usable earlier.
Say why, not only what
The most valuable line in any specification.
A developer who understands the purpose will notice when the stated rule does not achieve it, and will ask. One who knows only the rule will implement it exactly, including the case where it is wrong.
Several times a year this single sentence saves a rebuild.
A workable template
- Purpose — what problem this solves, in one sentence
- Trigger — exactly when it runs
- Rule — with a worked example
- Edge cases — the five questions above, answered
- Permissions — who triggers, who sees
- Failure behaviour — block, warn, or log
- Acceptance — the scenarios you will test
Half a page. It reliably costs less than one round of rework.
If you want customisations specified this way, see our ERPNext and Odoo customisation services, or talk to us.
Frequently asked questions
Usually not because the developer misunderstood, but because they built exactly what was described and the description omitted the cases handled by judgement in the business — amendments, cancellations, zero values, overlapping conditions, and records created before the rule existed.
Purpose in one sentence, the exact trigger, the rule with a worked example using real figures, answered edge cases, permissions for who triggers and who sees output, failure behaviour, and the acceptance scenarios you will test. About half a page.
Because it makes acceptance a check rather than a negotiation, and it forces edge cases to surface while they are still cheap to handle. Three or four specific scenarios with expected outcomes agreed up front is usually enough.
Because a developer who understands why will notice when the stated rule does not achieve it and will ask. One who knows only the rule implements it exactly, including in the case where the rule is wrong. That single sentence prevents rebuilds.
No. Requests accumulate — a report becomes a report with an export, then a scheduled email, then a filter — and each addition compounds testing and delays everything. Specifying one thing, accepting it, then specifying the next is slower on paper and faster in practice.