No vendor can anticipate every specific of a business. Sooner or later, an organisation makes a request the product does not cover as it stands: an approval chain that depends on an unusual criterion, a form that has to calculate, a check specific to one client. At that point, two bad answers are common: “that’s not possible”, or a piece of development delivered on the side that nobody maintains afterwards.
AlibeeZ has chosen a third way: not leaving you alone with the problem. The need is scoped with our teams, who know both the product and your sector, and it always follows the same path. The figure above sets out its four steps, numbered in the order they happen.
Before tailoring: what configuration already covers
Tailored work is not the starting point. AlibeeZ is first tuned through eight levers, none of which asks you to write code: over 400 business rules, workflows, forms, custom fields, historised tags, reports, alerts and home-screen newsletters.
Each has its scope, and knowing those scopes is how you know when you step outside them. A few examples from the product:
- an approval chain is set by role, amount, entity or project type, with no development needed as long as it stays within those dimensions;
- a simple form is built from the admin area; as soon as it carries rules or calculations, we scope it with you;
- fields, tags, reports, alerts and the announcements published on the home screen are entirely in your hands.
Most of the specifics people believe are unique are already covered by these levers. That is why the first step is to check.
The four steps, one by one
1. We map the need out
You describe the real case, not a specification. There is no need to write a requirements document: just explain what happens today and where it gets stuck. Our teams reframe the need, then first check whether existing configuration already answers it. It often does, and the request ends there, settled by a business rule, a field or a chain.
2. We tell you what it involves
Depending on the request, it is either configuration or development. You know which before committing, with the timeline and, where relevant, the quote. There is no grey area: the nature of the request is settled at scoping, not discovered on delivery.
3. You try it on a test base
Before production, the change is deployed on a test base loaded with your own data. You handle it under real conditions, then you sign it off or ask for it to be adjusted. Nothing goes live until you have signed it off. It is the rule rather than the exception, and it applies to the configuration levers too: a new field, for instance, can be deployed on a test base for you to try.
4. It joins the foundation
Once delivered, the change is maintained and follows the product’s updates like everything else. You are not left carrying a bespoke branch in a corner. AlibeeZ versions land continuously, with no interruption for your teams, and what was built for you moves with them.
What is included, what is quoted
AlibeeZ does not present tailored work as free. The terms are simple and stated up front:
| Configuration adjustment | Bespoke development | |
|---|---|---|
| Cost | Handled within your subscription | Quoted, discussed and agreed before any commitment |
| Before production | Tried on a test base, on your own data | Tried on a test base, on your own data |
| After delivery | Follows updates | Joins the foundation and is maintained with it |
In both cases the starting point is the same conversation. You do not need to know which side your request falls on to make it: telling you is what scoping is for.
Who you are dealing with
Scoping is not handed to an intermediary. At AlibeeZ, support, onboarding and development all happen in-house, with a technical team that answers for the whole stack, from architecture to ergonomics. The person who reframes your need therefore knows the product from the inside, and can check whether an existing rule covers it.
A specific need is met with development, not with a workaround: what is built for you becomes part of the product instead of living alongside it.
What it changes
- a request described in your own words, with no requirements document to write;
- the nature of the request, its timeline and any quote known before you commit;
- a change handled on your own data before it reaches production;
- no bespoke version to carry: what is delivered is maintained with the product.
Going further: the general criteria that separate configuration from development are set out in our article on configuration versus custom development. To see what configuration covers before you get that far, read the article on business rules and the one on approval workflows.
Frequently asked questions
How do I know whether my request is configuration or development?
You do not need to know in advance. You describe the real case, our teams first check whether existing configuration answers it, then tell you which side the request falls on, with the timeline and, where relevant, the quote, before any commitment.
Is a specific request chargeable?
It depends on the scope. A configuration adjustment is handled within the subscription. Bespoke development is quoted and agreed with you before it starts.
Can we test the change before it goes live?
Yes. The change is deployed on a test base loaded with your own data. You handle it, sign it off or ask for an adjustment, and nothing goes live until you have signed it off.
Does development done for us survive updates?
Yes. What is delivered joins the product foundation and is maintained with it. You are not pinned to a frozen version, and you keep receiving the product’s improvements.