Vrijbuiter modernizes their e-commerce experience. They switch to an agile and scalable headless Magento solution.
Open Commerce was involved in two phases. First, to explore the concept of headless commerce and develop a clear vision for a platform that would support both the extensive product catalog and the customer experience. Later, to build and guide an internal development team, ensuring the platform remained sustainable and agile.
During the concept phase, we helped Vrijbuiter create a roadmap and feature list that maximized the benefits of a decoupled front-end and back-end. This provided a solid foundation for the development phase, in which the team worked together with existing partners to bring the vision to life.
As ambitions grew, it became clear that in-house development capacity was needed. Open Commerce helped assemble a nearshore team that collaborated closely with internal stakeholders, from Product Owners and marketing to ERP specialists. Together, they optimized Pimcore for better product information management, stabilized the Vue Storefront front-end for a smooth shopping experience, and maintained Magento 2 for reliable performance and scalability.
This approach allowed Vrijbuiter to continuously improve the platform, ensure high performance, and stay agile for future growth. With an optimized e-commerce ecosystem, a dedicated team, and a clear digital strategy, Vrijbuiter now has a foundation not only to sell effectively but also to plan ahead.
Rebuilding the product data behind Vrijbuiter's webshop
An outdoor retailer's shop kept selling gear that had already sold out, and each fault led somewhere different. The cause sat between their systems rather than inside any one of them, so we mapped how product data moved and built the layer that keeps it consistent.
The shop they set out to build
We met Vrijbuiter in 2020, when Het Echte Werk, a concept and marketing agency in Rotterdam, brought us in to work on their new online concept. Het Echte Werk knew the brand and wanted someone alongside them who could say what a webshop could realistically be made to do.
Together we designed a shop where a customer could upload a hiking route as a GPX file, the format a watch or phone records a walk in, and it would read the climate and the terrain along that route, recommend the gear to match, and produce a checklist for the trip. Someone standing in a store could check stock and have what was missing sent home. Manuals for gear already bought would open on a phone with no signal, halfway up a mountain.
Our scope was the concept and a read on what could be built. The build itself went ahead with the agencies Vrijbuiter had already appointed.
Every one of those ideas rested on the same two foundations: product information rich enough to give advice, and stock figures that hold up wherever the customer happens to be standing. Foundations of that kind are harder to get right than the features sitting on top of them.
About a year went by before we spoke again, and by then those two foundations were where the trouble sat.
Working out what was actually wrong
They asked us to make the shop dependable. It ran on Magento, with a Vue Storefront frontend and Pimcore holding the product data, and keeping it standing had become a daily job: the frontend crashed and stayed down until somebody noticed and restarted it, and Pimcore would take a product update and lose it without telling anyone. We reviewed the frontend and Pimcore separately before committing to anything, then took over the codebase and worked through the faults.
Their ERP, which also runs the tills in their stores, reported every change in stock but had no way of reporting a zero, so when the last item of a product sold, every system further along the chain went on showing the last number it had received, and customers ordered gear that had already gone.
A price begins in the ERP as a recommended figure, adjusted by manufacturer and again by sales channel, and it could reach the shop late or in a form the shop read differently. Every system’s data made sense on its own, so every explanation pointed somewhere else. Their ecommerce manager and the colleagues who knew the catalog best were spending more of each week hunting incidents than moving the business forward.
So we put the firefighting down for a day and spent it at Vrijbuiter's offices, with their ecommerce, product and operations people in the room. The subject was data consistency, and the question we came to settle was whether the data they held could be cleaned or would have to be worked around. We went through each system in turn and drew the whole landscape. Four systems carried the shop between them: the storefront, Magento behind it, Pimcore holding the product data, and the ERP holding stock and price, with roughly thirty more around them for search, payments, marketplaces, customer service and shipping.
“Our job was to simplify it. To make it clear enough to see how everything flows, and where it breaks.”
Olena Vlasova, project manager, Open Commerce
We then traced the two journeys that decide whether a shop of this kind works, following an order from the customer's click to the warehouse, and a product from the moment it is created to each channel that sells it.
The stock fault was one instance of a wider pattern: product information arrived from dozens of suppliers through several systems, each with its own conventions, and every system further along the chain simply inherited whatever the one before it had sent. Nobody had ever written those conventions in one place.
The difficulty sat in the agreements between the systems rather than inside any one of them, which meant it would keep producing new symptoms however many old ones we cleared.
“The core of the issues always came from how the data was structured. Nine out of every ten problems we chased ended there.”
Attila Naghi, Magento developer, Open Commerce
How we decided to go about it
A full rebuild was the cleaner engineering answer, and we put it forward. The shop was trading, though, and rebuilding would have suspended precisely the corrective work the business needed most. We recommended steadying the platform first and restructuring the data underneath it in passing, one area at a time. Vrijbuiter weighed both and agreed.
Instead of declaring the whole catalog broken, we took a single category, trousers, and inventoried it end to end. That pilot told us what a working model looked like before we asked anyone to commit to one, and once it held up, we took the same approach through the rest of the catalog.
Vrijbuiter also wanted delivery capability closer to hand, so we assembled a team for them and managed the handover from their previous agency without interrupting the shop: a frontend developer, a Magento developer, Pimcore specialists and a project manager, working in agile sprints alongside Vrijbuiter's own Product Owner, marketing colleagues and ERP people. That arrangement ran for around a year and a half. Their ecommerce manager set the priorities, and their own catalog specialists tested the results, and each week both sides walked the same board together. The two sides worked as one team rather than two exchanging tickets, so when something needed explaining, the people who understood the products and the people who understood the systems were already in the same conversation.
What we built
A shared dictionary for the data
We introduced quality gates at each point where product information changed hands between systems, a translation layer whose only job is to take information in whatever form one system produces and hand the next system a version it can work with. A convention like an empty shelf now gets resolved once, centrally, rather than separately inside every system that receives it.
“We built a dictionary for the whole team, so everyone would start to understand each other in data terms.”
Sander Mangel, solutions architect, Open Commerce
A product data model that can carry advice
Working from a supplier's master data, we defined roughly fourteen structured fields per product, covering material, fit, length, activity, features, weight and temperature range. On top of that, we wrote rules that fill in what the supplier left out: stretch inferred from elastane content or an elasticated waist, a weight class inferred from the fabric, and suitability for work, sport or everyday wear inferred from cut, color and length together.
Those are the fields the 2020 concept had been waiting on, because a shop can only recommend gear for a wet week at altitude if it knows what its products are made for.
The catalog had been carrying one flat model of more than six hundred attributes, most of them irrelevant to any given product. We restructured it into category-specific sets, so that a pair of trousers presents the fields that describe trousers and nothing else.
A platform matched to what the business needed
We moved Vrijbuiter from Magento Commerce to Magento Open Source. The Commerce features had gone largely unused, and the few that mattered were straightforward to replace, so moving to the less expensive edition took tens of thousands of euros a year off their license fees. We cleaned up the hosting at the same time, removing storage charges the business was paying without benefit, and upgraded Pimcore from version 7 to version 10.
Where it stands now
The platform steadied, and the running costs fell. An empty shelf now reads the same way in every system that asks it, so the shop stopped offering gear it could not ship.
Where connected systems disagree about the same product, the cause usually sits in the space between them rather than in the software at either end, and the fix holds only when one place is made responsible for what the data means. Get that right, and the rest follows, as far as the customer looking for a jacket in their size, who finds it, orders it, and receives it.
Facing the same problem? If your shop, your ERP, and your product systems each describe the same item differently, the difficulty most likely lies in the data passing between them. That is worth mapping before anyone proposes a rebuild. Book a conversation with us.
