A store is mostly the things around the store.
The catalog and the checkout are the visible part. What decides whether a store is any good to run is everything attached to them.
Tax rates change, card networks change their rules, and carriers change their rates. Each of those is handled by a service whose only job it is, so the change arrives as somebody else’s deployment and the store keeps trading.
The same store carries a monthly subscription, a file a customer downloads once, and a pallet that ships. A customer buying two of those in one order goes through one checkout and gets one receipt.
Launching is a day. Running it is the job.
What a catalog has to do.
Recurring subscriptions
Billing on a schedule, with proration, pauses and dunning handled by the payment processor. A failed card retries and emails the customer before anything is cancelled.
Digital delivery
Files delivered through expiring, signed links rather than an attachment or a public URL. A download that was paid for once cannot be passed around indefinitely.
Physical fulfillment
Stock levels, variants and shipping rates, with the carrier quoting the rate at checkout. Orders go to the warehouse system in the format it already accepts.
Payments and tax
Card details never touch the site: the processor holds them and the store holds a token. Sales tax is calculated per jurisdiction at the moment of sale.
The hard part is the second year.
Launching a store is a project. Running one is an operation, and the difference shows up about eight months in.
By then the catalog has grown, somebody has added a product type nobody designed for, a payment method has been deprecated, and the tax position has changed in two states. A store built as a project handles none of that without a developer. A store built as an operation handles all of it from the administration interface.
So the work goes into the parts that get used daily rather than the parts that get seen once. Bulk edits and imports, because a price change across two hundred items is a Tuesday. Order search that finds a customer by the last four digits of a card or half a postcode, because that is what they give you on the phone. Refunds and partial refunds that reconcile, because the accounts have to close at the end of the month.
Reporting answers the questions somebody actually asks: what sold, what came back, which channel it came from, and what the margin was once the processor had taken its cut. In most stores those are four systems. Here they are one screen.
Everything that can be somebody else’s problem is. The processor holds the card details, so a breach of the site is not a breach of anybody’s payment data and the compliance scope stays small. The tax service tracks the rules. The carrier quotes the rate. What is left is the catalog and the customer, which is the part the business knows about.
