In Belgium, the cost of an e-commerce website cannot be estimated seriously from the number of pages alone. A manageable catalogue, a shop that can take orders and a platform synchronised with your stock are different levels of project. The budget therefore depends on the features, the connections required and the level of customisation expected. To get a usable estimate, first define the action your customer must be able to complete without human intervention.
The price on a quote can look easy to compare. Yet two proposals for an “e-commerce website” can cover very different things. One may include a few product pages and a contact form. The other may cover online payment, shipping rules, customer accounts, invoicing and synchronisation with your management software.
What type of e-commerce website do you actually need to fund?
Start by separating the catalogue from the shop. A catalogue presents your products, their features, their images and possibly their price. Your prospect then contacts you by phone, email or through a form. The content can be managed with a CMS, but no order is necessarily recorded online.
An online shop adds another functional layer. Visitors must be able to select a product, choose a variant, add an item to their basket, enter their details, choose a delivery option and pay. The site must then confirm the order, pass on the relevant information and allow it to be tracked. Secure payment is therefore only one part of a wider journey.
The project moves up another level when your shop has to manage stock, several warehouses, customer-specific prices, conditional promotions, business accounts or particular shipping rules. Synchronisation with an ERP, a CRM, accounting software or a warehouse management tool also introduces data exchanges that have to be designed, tested and monitored.
What action must the customer be able to complete without human intervention?
This question helps you frame the budget before requesting a quote. If the answer is “browse our products and contact us”, you are probably looking at a catalogue project. If it includes “order, pay, choose delivery and receive a confirmation”, you need to fund a shop. If you add “see the available stock and apply rules specific to each customer”, the scope becomes an e-commerce site connected to your back office.
Project scopes by feature
The items below are used to scope a Numinam project. They do not represent a universal price for the Belgian market. The budget depends on the number of products, the quality of the content provided, the languages, the business rules and the tools to connect. Without this information, a precise figure would give a false sense of certainty.
- Simple catalogue: a budget to scope for a manageable structure, a clear product presentation, search suited to the size of the catalogue and one or more page templates. This level does not necessarily include a basket, payment or automated order management. Check how many products are included, the import method and who is responsible for texts and images.
- Shop with online payment: a higher budget, because the project includes the basket, the checkout, the payment provider configuration, transactional emails, shipping rules and order testing. Check which payment methods are actually included, how refunds, taxes and variants are handled, and the abandoned-basket scenarios.
- E-commerce with stock management: a budget to establish according to which system holds the reference data. The scope may include stock, variants, orders, returns, reservations and synchronisation with a business tool. Check how often data is exchanged, how errors and data conflicts are handled, and which operations remain manual.
Some features can tip a project into custom development: account-specific prices, a product configurator, subscriptions, repeat orders, a marketplace, shipping calculated from several constraints, an approval workflow or reseller-only access. They should not be buried in a generic line called “advanced features”. Ask for them to be described separately, with their assumptions and limits.
For Numinam's overall price benchmarks, see the pricing page. The page on e-commerce website creation in Brussels will then help you clarify the context of your project.
What the initial budget covers
A coherent initial budget separates several stages. The architecture defines the catalogue structure, categories, journeys and navigation rules. UX and UI design turn that structure into a usable experience, on desktop and on mobile. You can read more about this on the UX and UI design page.
Development then covers building the interfaces, configuring the CMS or e-commerce solution, page templates, forms, basket, payment and emails. Testing should cover real journeys: account creation, ordering, accepted and declined payments, refunds, delivery, editing a product page and display on mobile.
Going live is a separate stage. It may include configuring the domain, hosting, certificates, redirects, backups and administrator access. Also ask what is planned for launch: support, training, checking the first orders and fixing blocking issues.
The client usually keeps an important responsibility for content. You have to provide or approve product pages, photos, prices, opening stock, shipping rules, terms and conditions, legal notices and returns information. If these items are incomplete, the schedule and the budget may change.
- Planned deliverables and features covered
- Number of page templates and languages included
- Number of products migrated or imported
- Connections included with external tools
- Client responsibilities for content and data
- Support planned before and after launch
Features that quickly increase the cost
Simple variants are usually easy to manage. The work grows when each variant has its own stock, price, image, lead time or shipping rule. The same applies to customer-specific prices, stackable discounts, conditional promotions and catalogues that differ by buyer profile.
Multiple languages and currencies add rules for content, prices, taxes and sometimes search visibility. Shipping can also become complex when it depends on weight, volume, geographical zone, product type or order value. Each rule must be described before the quote; otherwise it risks being treated as a later change.
A standard integration relies on a connector or interface already designed for both solutions. A custom connector requires business logic: which data is authoritative, when synchronisation runs, what to do with duplicates and how to correct an error. You also need to plan tests with representative products, customers, orders and stock.
Exchanges with an ERP, a CRM, accounting software, warehouse management or a marketing automation tool should therefore appear on a separate line of the quote. The price depends as much on the complexity of the data as on the number of systems involved.
What happens if an order or a stock update fails?
The answer should mention alerts, error logs, manual recovery and the person responsible for checking. Synchronisation without monitoring can create gaps between your shop and your internal management that are hard to detect.
Recurring costs to plan after launch
The build cost is only part of the budget. After launch, plan separately for hosting, any licences, payment provider fees, backups, technical maintenance and functional changes. These costs vary with the level of control you expect over security, updates and continuity of service.
Maintenance is not limited to stepping in when a screen stops working. It can include updates to the solution, monitoring, backups, compatibility fixes and a defined response time. Your order volume and how critical your back office is directly influence the level of service you need.
Ask for an annual running budget separate from the build cost. This lets you compare a solution that is cheap to launch with one that is better supported after launch. The article on website maintenance in Belgium goes into more detail.
How to compare two e-commerce quotes in Belgium
Compare the functional scopes before looking at the amounts on the first page. A cheaper quote may leave out product migration, variants, translations, payment methods, shipping rules or synchronisation testing. Work out the total project cost before making a decision.
Then check code ownership, data access, reversibility and maintenance terms. You need to know who can retrieve the catalogue, orders, customer accounts and content. Also ask for correction times by severity and what post-launch support includes.
Assumptions deserve particular attention. The number of products, the initial import, languages, carriers, VAT rules, external connections and migration from an old site can all lead to extra costs. Every assumption should be written down, including when the provider expects files from you.
Before requesting a personalised quote, prepare a short list: products and variants, checkout journey, payment methods, delivery zones, internal tools, languages, pricing rules and the level of maintenance expected. This scope lets Numinam reply on a comparable basis and separate what is configuration, integration or custom development.
