Cases

What we build and run.

No anonymous logos or invented percentages. Some are our own production environments; other examples are anonymised out of discretion. The figures we cite are accurate.

Own production and anonymised practice, no marketing figures.

Product data and digital commerce

Product data · e-commerce

A multilingual catalogue that stays correct every day

Our own e-commerce (Bopets) sells across .be, .nl and .eu, with 11,422 products in 6 language versions from dozens of suppliers.

Problem: Supplier data arrives in dozens of formats and is rarely sales-ready: missing fields, duplicates, price and stock changes.
Approach: Our managed service CatalogOps ingests the files, matches and enriches, holds exceptions back for human review and only publishes after approval.
Architecture: Suppliers → CatalogOps → Odoo (master data) and WooCommerce (webshop), with a daily controlled sync.
What stays managed: Daily runs, error follow-up and mappings run continuously; a new supplier release becomes a planned re-check instead of a crisis.

CatalogOpsOdooWooCommerceGS1 / GPSR

Web & SEO · content network

Our own network of more than 90 multilingual sites

Since 2004 we have built and managed our own network of more than 90 websites, multilingual and across borders.

Problem: Reliably managing content, multilingual setup, speed and findability across many sites at once, without maintenance becoming unmanageable.
Approach: A shared, maintainable foundation with correct hreflang and i18n, fast Core Web Vitals and a repeatable publishing and management flow.
Architecture: Modern, largely static frontends (incl. Astro) behind Cloudflare, on self-managed infrastructure.
What stays managed: Hosting, updates, monitoring and backups run continuously; this site (vimm.be) runs on the same approach.

AstroCloudflarehreflang & i18nCore Web Vitals

Product data · findability

Keeping thousands of products findable across countries

For a shop with thousands of products across several countries and languages, a correct catalogue is not enough: prices, stock and products must also stay quickly findable in search engines and marketplaces.

Problem: Changes in price, stock and assortment were picked up slowly; feeds and search engines lagged behind the real catalogue.
Approach: Structured product feeds, correct multilingual sitemaps and instant indexing, so changes are pushed quickly instead of waited out.
Architecture: Catalogue → feeds and sitemaps → search engines and marketplaces, with instant-indexing pings on every relevant change.
What stays managed: Feeds, sitemaps and indexing are monitored; new products and changes automatically follow the same path.

Product feedsIndexNowXML sitemapsSearch Console & Bing

Business systems and integrations

Business systems · integrations

One ERP core for multiple brands and countries

For an international trading group with several brands, countries and sales channels, orders, stock and invoicing ran through systems that barely understood each other.

Problem: Separate systems per brand and country, double entry and manual handover between webshops, accounting and logistics.
Approach: One Odoo core in a multi-company setup, with API connections to webshops, payment services, marketplaces and external feeds.
Architecture: Webshops and marketplaces → integration layer → Odoo (orders, stock, invoicing), with status and stock fed back.
What stays managed: The connections and data flows are monitored; a new channel or brand becomes an extension, not a new island.

OdooAPI integrationsEDI & feedsPayment services

AI automation · governance

An AI assistant that acts within strict limits

To manage a Microsoft 365 environment of more than 1000 users, we built an AI assistant for ourselves that takes over routine work but never acts outward without control.

Problem: AI that touches mail, contacts and user management is only usable if it does not perform irreversible or external actions on its own.
Approach: A three-tier permission model: autonomous reading and sorting; confirmation for changes; explicit approval with a dry-run for external actions such as sending mail or licence management.
Architecture: AI layer → permission control → Microsoft 365, mailboxes and contacts (Graph, IMAP, CardDAV), with a full audit trail of every autonomous action.
What stays managed: Human-in-the-loop on every external action, everything logged. Own R&D, not a sold product: it shows how we build AI with control and auditability.

Claude AIMicrosoft 365 / GraphIMAP & CardDAVAudit logging

Data · reporting

Bringing operational figures into one current dashboard

At one organisation, operational figures were scattered across several systems, with no single, current and shared overview for management.

Problem: Reports were assembled by hand from separate sources; by the time they were ready, the figures were already out of date.
Approach: Data pipelines (real-time where needed, batch where possible) that bring sources together, clean them and feed clear dashboards.
Architecture: Source systems → ETL and validation → data layer → dashboards for management and operations.
What stays managed: The pipelines and definitions are monitored; a new source or metric is added without breaking the overview.

ETL pipelinesData validationDashboardsAPI sources

Healthcare · collaboration

A platform for care coordination and patient follow-up

For a care context, we built a platform that supports patient workflows and collaboration between care providers, with attention to the privacy of sensitive data.

Problem: Coordination and follow-up ran through scattered channels and documents, without a structured, shared workflow.
Approach: A web application with clear patient workflows, roles and access rights, and collaboration between the care providers involved.
Architecture: Web frontend → application layer with role-based access → healthcare data model, with attention to privacy and logging.
What stays managed: Access, privacy and data management stay central; new workflows build on the same model.

Web applicationRole-based accessHealthcare data modelsPrivacy by design

Managed infrastructure and continuity

Infrastructure · continuity

Self-managed infrastructure with redundancy and backups

We run our own production environments not by reselling, but by setting them up and managing them ourselves.

Problem: Production environments that must stay fast, available and recoverable, without dependence on a closed vendor.
Approach: A managed stack with containers, high availability where needed, daily tested backups and monitoring with alerting.
Architecture: From the edge (Cloudflare) to the database: Coolify and Docker on EU infrastructure (Hetzner), with offsite backup.
What stays managed: Updates, patching, monitoring, backups and recovery run continuously; we know migrations and cutovers first-hand.

CoolifyDockerHetzner (EU)Cloudflare

Infrastructure · communication

Telephony across several countries on one managed PBX

An organisation with locations in several European countries had fragmented telephony: a separate solution per country, with no central management or consistent numbering plan.

Problem: Separate telephony per country, no central overview, and numbers and forwards that converged nowhere.
Approach: One self-managed phone system (Asterisk/FreePBX) with SIP trunks per country and GSM gateways where needed, and a structured numbering plan.
Architecture: SIP trunks and GSM gateways → PBX (Asterisk) → handsets and forwarding rules per location, with monitoring.
What stays managed: The PBX, trunks and routing are monitored and adjusted; a new location or country joins the same setup.

Asterisk / FreePBXSIP trunkingVoIP & GSM gatewaysMonitoring

Migration · continuity

From a closed platform to self-managed infrastructure

An organisation was locked into a costly, closed platform and wanted to move to self-managed infrastructure, without losing operations, data or findability.

Problem: Migrating a live environment without long downtime, without data loss and without breaking existing URLs and rankings.
Approach: A phased migration with a parallel environment, tested backups, URLs preserved via redirects and a planned DNS cutover.
Architecture: Old environment → parallel build on self-managed infra → controlled cutover, with a fallback plan.
What stays managed: After the switch, hosting, monitoring and backups continue; the organisation no longer depends on a single closed vendor.

Migration & cutoverRedirectsBackup & recoveryDNS

Infrastructure · control

One control panel for multiple environments and deployments

To avoid managing several applications and environments one by one by hand, we built our own control panel with an overview and deployment actions.

Problem: The state of separate environments and rollout actions was scattered; overview and operations took too much manual work.
Approach: A control plane that shows the current state of environments and bundles controlled rollout and management actions in one place.
Architecture: Dashboard → orchestration layer → multiple deploy targets and environments, with status feedback.
What stays managed: The panel and orchestration grow along; a new environment or target joins the same controls.

Node.js & ReactOrchestrationDeploy controlMonitoring

Cases

A comparable situation?

Tell us briefly where things get stuck for you. We look at whether and how our own approach fits your situation, honest about what is feasible.

Reply within one business day.

contact@vimm.be +32 (0)53 839 642