Product data · e-commerce A multilingual catalog 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 An own network of more than 90 multilingual sites
Since 2004 we have built and managed an 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
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
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
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
Product data · findability Keeping thousands of products findable across countries
For a shop with thousands of products across several countries and languages, a correct catalog 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 catalog.
- Approach
- Structured product feeds, correct multilingual sitemaps and instant indexing, so changes are pushed quickly instead of waited out.
- Architecture
- Catalog → 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
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
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 license 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
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
