The shop that cannot change a price

Building a shop is the cheap part. It gets expensive afterwards, with every change the business asks of it. So I do not judge a system by its launch. I judge it by its tenth change.

Launch day is the easy day

On launch day a shop is exactly what was planned. Products, prices and shipping rules are right, because they were only just entered. It is the one day that is guaranteed.

Then the business happens. A supplier raises prices. A product suddenly comes in three sizes. In December shipping should be free above a certain amount, in January it should not. Someone in Munich asks whether the site comes in German. None of these is unusual. Together they are what a shop actually does in its first year.

A shop that cannot change a price is rarely a broken shop. It usually works perfectly. It was built for launch day, not for the Tuesday after.

The change nobody saw coming

From 1 July to 31 December 2020, Germany cut its VAT: the standard rate from 19 to 16 percent, the reduced rate from 7 to 5. Every shop charging VAT there had to switch its tax rates twice in six months, and anyone passing the cut on to customers had to change their prices as well. Every country has its own version of this.

In one system the tax rate is a field in the settings. In another it sits in the code, in the invoice template and in a PDF price list. Same change, same law, same deadline. For one owner it is an hour of work, for the other a job for someone who happens to be on holiday.

Changes like that do not announce themselves, and you cannot foresee them all. You can know in advance what the unknown one will cost.

Where the cost lives

What a change costs rarely depends on its size. It depends on three things: who can make it, how many places it has to be made in, and what else can break along the way.

A new price that lives in one field takes a minute. The same price in the shop, on a homepage banner and in the PDF price list is three changes, and you forget the third. A new size the system expects as a variant is one line. In a system that has no variants it is a second product with its own stock count, and from then on the stock is never quite right again.

Building has become cheap. With a site builder or an AI, a shop is up quickly. Changing has not become cheaper at the same rate, because a change needs someone who understands what they are changing. The gap between the two is what a system costs you day to day.

Four questions before anything is built

Who makes the everyday change?

Prices, copy, products, images: that comes up every week. If the answer is not "you", you pay for every one of those changes twice, once in money and once in waiting.

How long does it take?

Have it shown, not described. Change a price, add a size, set up a December shipping rule, in front of you, with a clock running. What is awkward in the demo does not get easier in daily use.

What has to be touched?

One place or several. Every extra place is one that will, at some point, not get updated. Ask it plainly: when the price changes, where else does it appear?

Which changes need the person who built it?

Some will, and that is normal. A second language can be a rebuild rather than a setting, depending on whether the system expected it from the start. But the list should be short, and you should know it before you need it. Finding out in December that the December rule is a work order is finding out too late.

Before anything is built, write down the ten changes you expect in the first year. Not the features the shop should launch with, but the things that will change. That list is the better specification. A system that makes it easy is well built, whatever it looks like on day one.