The shop connects to operations.
ERP, PIM, logistics, marketplaces or custom pricing must work together reliably.
Building online shops
An online shop takes a few weeks these days: catalogue, basket, payment, shipping. If that is your task, take an agency or Shopware off the shelf, faster and cheaper than anything described here. This page is for what comes after: when the shop runs and still sells goods that went over the counter in the store days ago. At that point the shop is not the problem. The path between it and the systems that actually run your business is.
Entry as a shop set up and connected at a starting price, everything beyond that by scope. If an agency or a standard shop is the better choice for you, I say so in the first conversation.
Remote from Germany. Straight with me, no agency in between.
The starting point
Building shops is a solved problem. Shopware, a website builder, an agency: catalogue, basket, payment and shipping stand after a few weeks, at a quality that would have been a project ten years ago. Whoever needs that is in good hands there and pays less than for anything on this page. I say so here because otherwise it gets said at the end, once somebody has already written a quote.
The case this page is made for starts afterwards. The shop runs, and the stock figures are wrong: they come from a nightly export, and during the day the shop guesses. The store does not know what was sold online, the shop does not know what went over the counter. Orders sit in the shop but not in inventory management, and it surfaces at the reconciliation rather than before. The service desk keeps two windows open and retypes by hand. None of that is a shop defect. It is a missing path between systems that both already exist.
That is why the work here starts at the back: first the question of which system holds which data and how it reaches the shop, then the surface. With the motorcycle retailer that was exactly the reason for building the shop in house, not the look of it but the interlocking of inventory management, point of sale and store stock all the way to pickup in the store. The shop was the predictable part.
Does any of this sound familiar?Who this is for
For e-commerce, product and technical owners with a serious trading model. Catalogue, pricing, inventory, payment or fulfilment create requirements a standard shop alone cannot carry.
ERP, PIM, logistics, marketplaces or custom pricing must work together reliably.
Performance, checkout and data quality have direct commercial effects and are measured accordingly.
Architecture, tests, monitoring and handover matter as much as launch date and visible features.
What I do
First it gets written down instead of assumed: which system holds which data, in which direction it flows, how often, and over which interface. Almost always two systems sit side by side that both believe they know the stock. The result is a list of data paths with direction and frequency. It decides what is worth doing first, and it becomes the acceptance criteria later.
A standard shop off the shelf or an agency is the right choice where your range fits a normal product data model, where stock comes from one source, and where a ready-made connector already knows your inventory system. Then take that, and I say so in the first conversation. Building comes in where the assumptions of the standard break: stock across many stores rather than one warehouse, prices per customer or quantity, products that are configured rather than picked, or a point of sale that does not know the standard path. The most common good outcome, incidentally, is the mixture: a standard shop at the front, a built integration behind it. That mixture is exactly what the entry offer below is: the shop gets set up and connected in the same run. Not because setting it up is the craft: a Shopware shop stands in a day, and there is nothing remarkable about that. It is because otherwise you have two suppliers who have to agree on the interface, with you in between. Whoever only needs the shop and no integration still saves money with an agency, and that remains the right answer.
Between the shop and inventory management there is no cable, there is a queue. It has to do three things: be idempotent, so the same operation sent twice takes effect once; survive an outage on the other side without losing orders; and have an error path with a human owner at the end of it. Whether a kind of data runs in real time or on a cycle is decided per kind of data: stock in real time, master data hourly, images at night. Putting everything on real time costs money and only pays off for stock.
Store stock is where standard solutions stop first. It changes at the till rather than in the warehouse, and it changes fast. Showing it in the shop needs a point of sale reachable online, a rule for reservations, and an answer to what happens when the last item sells in the store and in the shop at the same moment. Pickup and returns in the store hang on the same paths. Where your point of sale cannot do this, I say so beforehand and not in the third week.
Products that need explaining do not fail at checkout, they fail before it: does this part fit my model, in which version, with which accessories. That needs product data with structure, a search that understands attributes, and rules for what fits together. Only on top of that is a model for recommendations worth anything. With the motorcycle retailer it delivered around 10 per cent more conversion, measured against a control group, and more important than the model was the data quality out of inventory management. Without clean attributes a recommendation system is an expensive random generator.
A shop does not carry its load evenly. A campaign launch, the start of the season, a discount day: the hour that counts is known and rare. That is what you size for, not the average. Part of that is what happens when inventory management does not answer during that hour: the shop keeps selling, the operations stack up in the queue and catch up afterwards instead of getting lost.
Is your shop failing at the integration rather than at the shop?
Send me your systems and the path the data takes today. You get an assessment of what can be connected and what cannot, before you commission anything.
How it runs
Four steps, two before and two after: the conversation and the recording come ahead of the order, the final price comes out of the recording, and only then do the four weeks start. No step assumes you commission the next one.
Which shop, which systems, which data runs how today. After that I tell you whether the integration is your bottleneck. If a standard shop with a ready-made connector covers your case, I say that too, and then the conversation is short.
Which system holds which data, which interface it has, which direction and which cycle are needed. Out of that comes the list of data paths and the decision on which one gets built first. This step sits ahead of the order: the final price comes out of it, and the four weeks only start once that price is agreed.
Where no shop stands yet: installation, base configuration, tax rates, up to three payment methods and three shipping methods, the legally required pages carrying your copy, and the standard theme brought onto your brand. Then the catalogue out of one source system, in one run with a check log. Where your shop already stands, this step falls away: the starting price stays the same, and the same figure then buys a deeper integration instead of the setup.
The work runs against your own data, not against sample files. The new path runs alongside the existing one, you compare the results, and deviations are welcome during that time. After that the path goes live, and the code, the rules and the operations are documented. From then on it runs without me, and the second system is an extension rather than a fresh start.
The other side
The total is not printed below, because I do not know it. The items I do know, and in retail they are easier to measure than elsewhere: every cancellation, every return and every service enquiry has a number and a date.
The entry offer below starts at 6,900 euros and covers the shop set up along with one integration. Whether it pays off is something you work out with your own figures.
Entry offer
Starting price for a setup with one integration to a system that has a documented interface and test access. The setup can be described, the effort of the integration sits in the other system. The recording therefore comes ahead of the order: the final price is settled after it, and only then do the four weeks start.
A shop that is set up and already talking to one of your systems. Both from a single supplier, because otherwise two suppliers have to settle the interface between themselves with you in the middle. Setting it up is the predictable part of that, the integration is the part everything hangs on. Afterwards you also know what the next system costs.
What you get
What you do not get
The outcome
The shop stands in your environment, with payment methods, shipping methods and the legally required pages, and what it displays is what the system of record holds, as of now rather than as of last night. Overselling is then a decision you take because you want to sell goods you do not hold, not a side effect of an export.
Idempotency is the least spectacular part of the work and the one you feel for longest. Duplicate orders, duplicate bookings and the corrections that follow them stop arising at this point.
Whatever does not go through lands in a list with an owner and a follow-up date rather than in a log file. The question "did anything get stuck yesterday" is a query afterwards, not a search.
The queue, the log, the error path and the operations are built once. Connecting another system after that is legwork with a known effort and not a second project.
Technologies I use

Who you are talking to
I am Tim Rutte. More than 20 years in software development, including shops whose revenue depended on the connection to inventory management and point of sale. You talk to the person who touches your code, from the first call to the handover.
Common questions
Probably not, and I would rather say so now than after the quote. Where your range fits a normal product data model, stock comes from one source and nobody has to connect a store, an agency or Shopware off the shelf gives you the same result faster and cheaper. The entry offer below changes none of that: the fact that it contains a shop being set up does not make setting shops up the offer here. It is in there because it comes with the integration from a single supplier. You are in the right place here when the shop is not the hard part but what hangs behind it is.
Often it is enough. A connector covers the standard case, and if your case is the standard case, take it. It stops where the assumptions no longer hold: stock across many stores rather than one warehouse, reservations for pickup, prices per customer or quantity, products that are configured rather than picked. And it rarely says anything about what happens when the other side does not answer for an hour. That is precisely the work here.
No, the Shopware migration has a page of its own. It is about a move inside one product, with plugins, themes, data migration, a cutover date and a way back, and the entry offer there is a first migration run. This page does not ask which shop system you are on, it asks what hangs behind it. The two often coincide: then you migrate first and integrate afterwards, and I tell you the order in the first conversation.
Usually not. Where your shop stands and can be connected, the integration goes to it. The starting price stays the same: the step falls away, and the same figure then buys a deeper integration instead of the setup. A shop gets set up afresh in two cases: where there is no shop yet, or where the existing one structurally will not allow the integration, because it has no extension points or because every adaptation was made in the core and gets lost at the next update. Which of those applies comes out during the recording, not in the third week.
Through the point of sale, and that is what it stands or falls on. Where your till system is reachable online and reports sales promptly, store stock can be shown in the shop and reserved for pickup. Where it only writes into inventory management at night, real time is not available, and the honest answer is then a figure with a timestamp rather than one pretending to be current. What your point of sale can do is settled during the recording, not in the third week. None of it sits in the entry offer: reservation rules and the race for the last item are a project of their own.
With the motorcycle retailer it was around 10 per cent more conversion, measured against a control group. More important than the model was the data quality: without clean product attributes from inventory management no recommendation would have worked. That is also why it is not part of the entry offer. Product data first, then the search, then the recommendations, in that order, otherwise you pay for a model that sorts bad data.
The entry offer starts at 6,900 euros net: a Shopware shop set up and ready to run, with the catalogue taken over and one route connected, with a dependable reconciliation, an error path and a log, live within four weeks. Why a starting price and not a fixed one: the setup can be described, the effort of the integration is set by the other system on the far side. For the setup part the figure therefore holds within the scope listed above; what the integration costs comes out of the recording, and that sits ahead of the order. You see the final price before anything is built, not in a supplementary invoice. A theme of your own, search, recommendations and a configurator are projects of their own and are quoted by scope.
The shop and the path behind it run in your environment, the code, the rules and the operations are documented, and you can carry on with it without asking me. A second system, a second data direction, a theme of your own, the search or a configurator are extensions with quotes of their own. The effort for them sits in the list you get at the end of the entry offer rather than in an estimate.
Other services
Backends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn moreMoving from Shopware 5 to 6 is not an update, it is a move: new architecture, new extensions, the data comes along. Made plannable.
Learn moreFrom the incoming document to the posted entry without retyping: read XRechnung and ZUGFeRD, match against the purchase order, route the approval, hand over to your ERP, with a full trail.
Learn more