All services

Building online shops

The shop is the easy part. The hard part is what hangs behind it.

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.

Inventory & point of saleStore stock in real timeSearch & recommendationsFrom 6,900 €
What you get
  • A shop connected to your systems instead of standing next to them, set up and connected from a single supplier where both are missing
  • Stock, prices and availability from the system of record, not from the copy taken last night
  • Store stock in the shop and in-store pickup, as far as your point of sale allows it, as a project of its own rather than part of the entry offer
  • Orders that arrive in the target system even when it is not answering
  • Search and product recommendations working off your product data rather than a default index, as a project of its own rather than part of the entry offer
  • A log per operation and an error path with an owner instead of a silent drop
Scope & working together

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

The shop is the surface. The system sits behind it.

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?
  • The shop displays goods that went over the counter in the store long ago.
  • Stock figures come from a nightly export, and during the day the shop guesses.
  • An order sits in the shop but not in inventory management, and it only surfaces at the reconciliation.
  • The service desk has two systems open and transfers by hand.
  • A configurator runs as a spreadsheet next to the shop, maintained by one single person.
  • The home-grown system still holds, but nobody dares to touch it any more.

Who this is for

For commerce businesses where the storefront is only the visible part of the system.

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.

01

The shop connects to operations.

ERP, PIM, logistics, marketplaces or custom pricing must work together reliably.

02

Technical details affect revenue.

Performance, checkout and data quality have direct commercial effects and are measured accordingly.

03

You need a product that lasts.

Architecture, tests, monitoring and handover matter as much as launch date and visible features.

What I do

Connect.
Reconcile.
Prove.

01

The system landscape as it really looks

System of recordData pathsInterfaces

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.

02

Buy or build, answered honestly

Buy or buildStandard shopOne supplierDecision criteria

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.

03

The reconciliation that survives a backlog

IdempotencyQueueError pathLog

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.

04

Store stock, pickup and returns

Point of saleReservationPickupReturns

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.

05

Configurator, search and recommendations

ElasticsearchProduct attributesConfiguratorRecommendations

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.

06

Operations: peaks and recovery

Load peaksAmazon ECSTerraformRecovery

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

How this 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.

STEP 01

A 30 minute conversation

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.

STEP 02

Recording the system landscape

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.

STEP 03

Setting the shop up and taking the catalogue over

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.

STEP 04

Connecting, testing against real data, handing over

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

What the missing integration costs you today.

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.

  1. 01
    OversellingHow many orders did you have to cancel last year because the goods were no longer there?
  2. 02
    Returns from wrong informationHow many returns go back to the shop showing something different from the warehouse or the store?
  3. 03
    Manual work between two systemsHow many minutes a day does somebody spend transferring orders, stock or prices by hand?
  4. 04
    Stock nobody can seeHow much of your stock stays invisible in the shop because it only knows the central warehouse and not the stores?

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

Shop set up and connected. From 6,900 €

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

  • A Shopware shop set up and ready to run in your environment: installation, base configuration, tax rates, up to three payment methods and three shipping methods from existing extensions, the legally required pages carrying your copy
  • The standard theme set up and brought onto your brand: logo, colours, typefaces and a home page from the standard building blocks, one draft and one round of corrections
  • Your catalogue taken over from one source system: articles, prices, stock levels, images, in one run with a check log. One language, one currency, one sales channel, up to 50 variants per article
  • One route between the shop and one of your systems, your choice of inventory management, point of sale or PIM: one data direction for orders, stock levels or product data, the reconciliation idempotent, so the same operation sent twice takes effect once
  • A documented error path with an owner and a log per operation, tested against real data from your own stock
  • Operations written down and handed over: where the shop runs, how it is updated, what to do when something fails
  • The list of what sits differently in the next system, with the effort per item

What you do not get

  • No theme of your own and no design concept. What gets set up is the standard theme with your colours, typefaces and logo. No photography and no copywriting either
  • No second connected system and no second data direction at the starting price, both are quoted beforehand
  • No second source system for the catalogue, no second language, no second currency and no further sales channel. No variant matrix beyond 50 variants per article either, no cross-selling and no carry-over of old SEO URLs
  • No store stock in the shop, no in-store pickup and no in-store returns, not even where the point of sale is the connected system. Reservation rules and the race for the last item are a project of their own
  • No search, no product recommendations and no configurator. Those are projects of their own with their own quote
  • No migration from one shop system to another. Shopware 5 to 6 has a page and an entry offer of its own
  • No cleanup of your product or master data and no back-entry of historic stock. What is there is what gets taken over
  • No changes to inventory management, point of sale or PIM. The work happens at their interface, not inside them
  • No sale and no procurement of software or licences. The hosting, extensions from the store and a paid Shopware plan, where one is needed, run in your name
  • No payment plugin of my own. What gets set up is whatever an existing extension covers; accounts, contracts and activation with the payment provider sit with you
  • No online marketing, no SEO retainer and no campaigns. The shop goes live technically, marketing it is a different job
  • No rule changes after acceptance. Whatever surfaces while running alongside is worked in before that, afterwards it is an addendum
  • No ongoing support without an agreement of its own
  • The recording of the system landscape comes ahead of the order. The final price comes out of it, and the four weeks only start once that price is agreed
  • A system to be connected, settled before the start, and the decision whether the shop gets set up afresh or the existing one stays
  • Access to the target environment with a test instance where things can be checked before the cutover
  • A documented, reachable interface on both sides, with test access and a contact. Without it, that is a project of its own
  • A person on your side who can decide payment methods and shipping methods bindingly, without a second round in house
  • Your product data out of one source system, in a readable, exportable form: articles, prices, stock levels, images, with one unambiguous key per article
  • Hosting that meets the Shopware system requirements. On a bare server the workers, cron, Redis, the search service and mail delivery are an item of their own
  • The hosting and, where a paid plan is needed, the Shopware plan run in your name. The Community Edition is free of charge; I set things up, I do not buy them
  • A person who can say bindingly which system wins when two of them disagree
  • The starting price holds regardless of how long the work takes
  • Live within four weeks, counted from the day the price is agreed and the access is in place
  • What is produced runs in your environment and belongs to you, including code and documentation
  • Price net, plus VAT
  • With several tenants, several shop instances or more than 100,000 articles the scope is agreed beforehand
  • You are committed to nothing further. Some teams build the second system themselves afterwards

The outcome

What is different afterwards

The shop runs, and the stock figure is right

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.

An operation sent twice takes effect once

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.

Errors have a place

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 second system is cheaper

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

Technologies I use

Shop
  • Shopware
  • PHP 8
  • Symfony
Backend
  • Golang
  • PostgreSQL
  • Amazon SQS
Search
  • Elasticsearch
  • Manticore Search
Inventory & point of sale
  • SAP
  • Microsoft Dynamics
  • Sage
Interfaces
  • REST
  • GraphQL
  • Webhooks
Payment
  • Stripe
  • PayPal
  • Klarna
Operations
  • Amazon ECS
  • Terraform
  • Docker
  • CloudWatch
Tim Rutte, Cloud & Software Architect

Who you are talking to

Directly with me as a freelancer. No agency in between.

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.

  • 20+years in software development
  • 50+successful projects
  • 2003working remotely since then
More about me

Common questions

Common questions about online shops

We simply need an online shop. Is this the right page?

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.

Why is a ready-made connector to inventory management not enough?

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.

We want to go from Shopware 5 to 6. Is that the same service?

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.

Does the shop have to be set up afresh for this?

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.

How does store stock get into the shop in real time?

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.

What do search and product recommendations actually deliver?

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.

What does it cost?

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.

What happens after the four weeks?

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.