what sets the price.
The price of an ERP to webshop integration follows from three things, not from the names of the systems alone.
- The kind of systems. A system we know well is less work than a legacy system or one we have not connected before.
- The number of flows. Each flow of data between two systems, a route in Alumio, adds work.
- Overall complexity. Exceptions in your process, requirements for dependability and the way systems offer their data decide how much there is to build.
known system or legacy system.
A system with a documented API, a test environment and predictable behaviour connects quickly. We know how it authenticates, reports errors and where its limits are.
A legacy system rarely has that. Often there is no API but a database, a folder of files or an export that runs overnight. Documentation is missing or out of date. Then you first have to work out how it behaves before building. That investigation and the extra testing make the difference in price, not the brand.
how many flows, and in which direction.
An integration consists of separate data flows: products, stock, prices, customers, orders, order statuses, shipments and invoices. Each flow has its own source, destination and rules.
Direction counts too. Stock from ERP to webshop is one flow. Orders into the ERP and the status back are two, each with its own checks. The more flows and directions, the more there is to build and watch over. A route describes the scope, not the price.
data quality and mapping.
Two systems rarely call the same thing by the same name. An order status in the webshop does not exist in the ERP, a VAT code has a different format, a customer is duplicated or has no email address. Every deviation needs a decision: convert, clean up or drop.
Those decisions belong to the process owner on your side. The cleaner the data and the clearer the mapping up front, the fewer exceptions we have to catch and the lower the price.
sequence and dependencies.
Flows depend on each other. An order refers to a customer and products, so those have to exist first. The integration has to keep that sequence and handle what goes wrong: a product that does not exist yet, a customer that cannot be found, a system that briefly does not answer. The more dependencies, the more design and test work, and that shows in the price.
testing, validation and go-live.
After the build comes testing with real data in a test environment, your check of orders, products and stock, and the switch-over, when the integration goes live while the shop keeps running. With high volumes or strict dependability requirements, say not a single duplicate order, this part weighs more heavily.
the Alumio library as a starting point.
For many systems Alumio has an existing connection in its library. It gives a head start: you do not begin from zero. But most companies have oddities in their process, such as their own way of pricing or an exception for one customer group, and those need bespoke configuration. That is why the complexity of your process sets the price, not the name of the system. Read more in Alumio template or custom?.
why we do not name an amount without a conversation.
Two integrations between the same systems can be far apart in price, because the exceptions in your process differ. A fixed amount without knowing what has to happen would be a surprise for one of us.
how the price comes about.
Before we quote, we check technically whether your integration is possible. Then we agree the scope and give a fixed price for that scope. So you run little to no risk: the price is settled before we start. Adjustments after that are on time and material, with an estimate up front. For ad-hoc support we charge €150 per hour, and the day rate is €1,000 (excl. VAT).
what is in scope and what is extra.
The fixed price covers what the quote says: the named flows and exceptions and the agreed way of testing. Extra is what falls outside it: a flow added later, an exception the quote does not name, or a system that changes midway. You hear about it before we do it.
what you want to see in a quote.
Ask every party to write down the same things, so you can compare:
- Which flows are connected, in which direction, and which are not.
- Which exceptions in your process are included.
- What counts as extra work and how it is charged.
- How testing is done and when you sign off.
- Who supplies what: access, documentation, test data and a contact per system.
- Whether the platform license is included or separate.
what you can do to keep the price down.
- Describe which data really has to be connected and which does not.
- Make the exceptions in your process visible up front, including the rare ones.
- Clean up known dirty data before the integration goes live.
- Make sure the owner of each system is available for questions.
Read more about how we work on the pricing page. Tell us which systems you connect, and we will tell you in one call what the price depends on.
