Prax

When there is no predecessor system, you cannot derive what the platform needs to handle from order volumes or warehouse throughput. So you derive the criteria from the goals instead. For Prax there were three that mattered: the platform had to support fast growth, serve B2B and B2C in parallel, and integrate deeply into an existing system landscape — ERP, pricing and approval logic, compliance checks in the checkout. Magento, Shopify and Shopware were all on the table.

What ultimately spoke for Shopware was the maturity of its ecosystem in the German market: a large number of comparable shops running in production, integration partners readily available, and a developer market you can still draw on in five years. That is a harder criterion than it first sounds. You are not only deciding on software — you are deciding on the availability of expertise across the entire lifespan of the platform.

With Magento it was not an exclusion but a trade-off. Both platforms would have met the requirements — that was never in question. Every platform decision is an exchange: you gain flexibility in one place and pay for it elsewhere in complexity, operational effort or dependencies. With Magento the compromises would have fallen in areas that were critical to Prax's goals; with Shopware they fell where they constrained the project less. We deliberately put Magento in the running — we have worked with it for many years and could have delivered the project on it. For this particular setup, Shopware was the better fit.

Shopify would have supported the growth as well. What decided it were the requirements on the order process: sanctions list screening in the checkout, VAT ID validation for business customers, different approval logic for B2B and B2C. The deeper you need to intervene in the order process, the more control over the code you need. That is why we ruled out a SaaS model early.

The most demanding integration was the sanctions list screening in the checkout. Prax sells tools that, depending on their intended use, can fall under export control regulations. So customer data is checked in the background on every order before it enters the order workflow — a hard requirement, not a nice-to-have, and it had to fit cleanly into the purchase flow without damaging conversion.

The ERP integration ran more smoothly than you would expect with a partner you are working with for the first time. The reason was exactly the ecosystem effect that shaped the platform decision: the ERP vendor had delivered another Shopware project shortly before and was able to port existing components rather than start from scratch. Alongside that we built VAT ID validation for business customers and an appointment booking tool that lets customers pick an available slot to speak with a product specialist.

That there were no existing processes to orient ourselves around — which is both an advantage and a cost. The advantage: we did not have to migrate grown processes, we could design the target state from the ground up together with the business side. In a migration you almost always carry legacy baggage with you. Not here.

The cost was in the sequencing. Fundamental decisions — which system is the source of truth, which has read-only access, where data flows, how returns and complaints are handled — had to be made in parallel with the build. So we invested a lot of time in workshops before any features were written. The real challenge was not technical. It was making a large number of directional decisions in a short window without any of them becoming expensive to correct later.

There are many subtle differences you do not think about at first. The most obvious is basket size — at Prax the business customer basket runs roughly ten times higher than the consumer basket. That changes the requirements across the entire order process, from payment methods through to approval logic.

It becomes concrete at payment. If a consumer wants to buy on invoice, you verify date of birth and whether the delivery and billing addresses match. For a business customer, a VAT ID check is usually enough to clear the order. Differences like these run through the basket, the payment options and the checkout — and they are the reason a shop serving both audiences is more than a shop with two price lists.

The first commit was in early April, with go-live planned for the first week of October. We went live at the end of January. The team was deliberately lean: project lead, one frontend developer, one backend developer and one QA engineer.

The delay was not down to development — we were finished on the planned date. But a launch where the brand, the product range and the shop all come into existence at the same time depends on more than the software. When dependencies outside the project team shifted, the date moved with them. For a brand launch that is the rule rather than the exception.

Total cost of ownership. Infrastructure runs in the low five figures per year — for a shop of this size that is a noticeable share of overall cost, and it is the item most often underestimated with Shopware.

On top of that come extension licences. In B2B especially, the good extensions are not cheap, and every additional requirement pushes TCO further up. If we had known the full scope of requirements from the start, we would have weighted this more heavily in the platform decision. That does not mean the decision was wrong. But anyone evaluating Shopware purely on platform licence cost is calculating too narrowly — operating and extension costs belong in the model from day one.

It continues in run mode, and that was the intention from the start. A shop is not finished at go-live — it is ready to start. New requirements keep coming out of day-to-day operations, and we implement them.

A large part of the work is advisory, and that is the division of labour we agreed on: Prax knows its market and its products, we bring in what a shop needs technically and from a compliance perspective. GDPR compliance and consent management were part of the requirements from the beginning — thinking that through is our job, not the merchant's. Most recently, disclosure obligations for AI-generated content were added. We raise topics like these proactively, before they become urgent.

Around 80 percent of the project ran very well. The remaining 20 percent came down to dependencies outside the project team — and that is exactly where the lesson sits. Supply chains, partner resources, approval paths: I would put external dependencies like these on the table with the client even earlier next time.

Everything internal can run to plan and the date still moves. Making those dependencies visible before the timeline is fixed is the difference between a realistic plan and an optimistic one. We now build that into project initiation as standard and ask explicitly, at the outset, about everything outside our own control.