The questions buyers actually ask

Because the licence is not the whole cost of a system. Alibera adds automation and modules you do not have today, and it lowers what you spend later on integrations and on building new functionality. If your current system cannot be extended without a project every single time, that is what you are already paying for.

It works until it stops scaling. Manual processes are error prone and they cost time that nobody logs. Alibera automates the repetitive parts, keeps one set of data instead of several, and records who changed what. The bigger you get, the more that matters.

Because we are close to you and we move faster. A small local team adapts the system to how you work instead of routing your request through a global roadmap, and support comes from people who know your installation. If you need a globally standardised ERP for tens of thousands of people, we are honestly not the right choice, and we will say so early.

We analyse your processes before we configure anything, and the modules are set up to match what we find. It is built to be adapted rather than to impose one fixed way of working. The implementation page sets out how that analysis runs and what we need from you for it.

It is usually the reason a company talks to us in the first place. Non-standard processes are where a configurable system earns its place, and custom modules or adaptations can be developed for the parts that nothing off the shelf covers.

Yes. Custom functionality is developed and quoted per project, based on what it takes to build rather than off a published rate card. How pricing works explains what sits inside the core and what is billed separately.

The aim is to end up with fewer, not more. Alibera can replace several of the tools you run today and connect to the ones you keep, so the data lives in one place. Send us what is in your stack and we will say plainly what it can and cannot replace.

It is priced as a core system plus the modules you use, and it scales with people and modules rather than with how many documents you push through it. The full system is positioned on what it returns over time rather than on being the cheapest thing you can buy. How pricing works has the detail.

Yes. You can take the core system and add or build your own modules on top of it, which costs less than a full implementation. The caveat is explicit: Alibera does not take responsibility for the security of modules you build yourself.

Payment is staged, with a deposit at the start and instalments tied to delivery, and the schedule is written into the contract. If the work extends, the cost is adjusted with you rather than quietly accrued. The implementation page lists what usually causes the delay in the first place.

Then scope, timeline and budget are renegotiated with you, openly, at the point we know. You decide what to cut, what to postpone and what to pay for. Finding out at the end would be worse for both of us.

A small team means the people who scoped your project are the people who build it, and you talk to them directly instead of through an account layer. The same specialists stay on it from discovery through to go live, and the process is transparent at every stage, so you always know where the project stands.

Your data can be exported, and you can run Alibera on your own server instead of ours. The modular structure also means you can add or build your own modules rather than waiting for us to do it. Security and hosting covers what on-premise means in practice.

An on-premise installation keeps running on your own hardware regardless of what happens to us. Cloud customers keep the service for as long as they subscribe, and data can be exported to another system at any point. That is the honest answer, and it is part of why the on-premise option exists.

Yes. On-premise puts the database and the application on your own server, under your control, and you can run your own restores. Security and hosting sets out the differences between the two models, including the ones that are not in our favour.

Adoption follows from two things: people seeing the time they get back, and training that arrives before the change does. Training is phased per module and the rollout can be phased too, so nobody has to learn everything in one week.

The system is capable, and most of that capability sits behind the forms and views people actually use. Someone entering an order sees an order screen, not the configuration that makes it work.

A new fiscal period is a natural point to switch, because the books start clean and there is less to carry across. Work backwards from that date, since discovery, proposal and data migration all have to fit in front of it. Talk to us once you have a target in mind.