Short answer: configuration is everything the product already knows how to do and simply needs setting; development is everything it does not know how to do yet. The first is delivered in days and follows upgrades on its own. The second is quoted, argued over, and commits your company well beyond its initial invoice.
What is the difference, concretely?
Configuration switches on or tunes a behaviour already present in the product: an entry unit, an approval threshold, a validation chain, a field, a report. The code does not change; its configuration does.
Custom development adds a behaviour that did not exist. The code changes, so somebody has to maintain it, and somebody has to decide whether it joins the standard product or lives alongside it.
| Configuration | Custom development | |
|---|---|---|
| Timeline | Days | Weeks to months |
| Cost | Usually inside the subscription | Quoted and agreed beforehand |
| Upgrades | Followed automatically | Check: merged into the core, or carried apart |
| Reversibility | A setting can be changed | A development has to be replaced |
| Who does it | Your teams, or the vendor | The vendor |
How do you know which side your need falls on?
Five criteria settle the vast majority of cases:
- Is it data or behaviour? Adding, classifying or reporting data is almost always configuration. Calculating, controlling or triggering is more often development.
- Does the need already exist under another name? A great many “specific” requests are known cases badly named. It is the first thing to check, and it is often where the discussion ends.
- How many other clients would want the same thing? A shared need stands a chance of joining the core product, and therefore of being maintained for you rather than by you.
- Does it touch a screen or a mechanism? A screen is easier to adjust than an invoicing or margin-calculation mechanism.
- What happens if you do not do it? If the answer is “we carry on with a spreadsheet”, the need is real. If it is “we would do it another way”, it deserves rephrasing before it is quoted.
What custom development really costs
The initial quote is the visible part. Three costs follow, and they are rarely priced at the moment of the decision:
- maintenance, if the development lives beside the product rather than inside it;
- version lock, when an upgrade can no longer be applied without breaking the bespoke work, the most expensive scenario, because it also deprives you of every improvement you did not ask for;
- dependency, when one person at the vendor is the only one who knows how your case works.
Development merged into the core product avoids all three. That is the question to ask, and it matters more than the price.
The questions to ask before signing
- Is my request configuration or development? And why?
- Is there already a way to answer it through configuration, even imperfectly?
- If it is development: will it join the standard product or stay specific to my installation?
- Who maintains it, and what happens at the next major upgrade?
- Can I try it on a test base, on my own data, before production?
The third question is the one that protects you best, and it is also the one most often forgotten.
What a test base is for
A need described out loud and a need handled on your own data are not the same need. Deploying the change on a test base before production surfaces the forgotten cases while they are still cheap to fix, and lets you sign it off, or ask for an adjustment, without exposing your teams to a setting that does not suit them.
It is also the best way to avoid the most expensive outcome in an ERP project: a development delivered exactly to specification, and unusable in practice.
In practice
At AlibeeZ, more than 400 business rules ship ready to be switched on through configuration, alongside seven other levers: fields, tags, forms, workflows, reports, alerts and internal announcements. Anything that falls outside configuration is scoped, quoted and discussed before it is committed, then joins the core product so it is maintained with it. The detail is on the customisation page.
Frequently asked questions
What is the difference between configuration and custom development?
Configuration tunes a behaviour already present in the product: the code does not change, only its settings do. Custom development adds a behaviour that did not exist, and therefore code that somebody will have to maintain.
How do I know which side my need falls on?
Ask yourself whether it is data or behaviour. Adding, classifying or reporting data is almost always configuration; calculating, controlling or triggering is more often development.
Does custom development survive upgrades?
It depends on one thing: is it merged into the core product or carried alongside it? Merged, it is maintained with everything else and follows upgrades. Carried alongside, it can lock your version and deprive you of improvements you never asked for.
Why use a test base before going live?
Because a need described out loud and a need handled on your own data are not the same need. A test base surfaces the forgotten cases while they are still cheap to fix, and stops a development that matches the specification from turning out to be unusable.
