Hosted or custom online store: what hurts in year three

Hosted or custom online store — most comparisons end at the size of the fee and how quickly the first version goes live. Those are first-month criteria. The problems start in year three, when you already have a large catalogue, order history, earned search visibility and a live warehouse integration. Below are the six criteria that decide it then, each with the specific question to ask before the decision rather than after it.

Hosted or custom online store: what actually separates them

A hosted store runs on the vendor’s software and servers: you pay a recurring fee for access, and the code, the infrastructure and the updates stay on their side. A custom store is one whose code and database belong to you — built for the project, or based on an engine you install on your own server.

In the Polish market, and a company operating in Poland is most likely choosing between exactly these, the hosted model includes Shoper, IdoSell, Sky-Shop, Selly, AtomStore and Shopify. On the self-installed side sit PrestaShop, WooCommerce and Magento (Adobe Commerce). The boundary is not sharp: an open-source engine can be bought with managed hosting, and a hosted platform can be extended with your own presentation layer over its API.

Both models run high-turnover shops today. They differ not in “quality” but in where responsibility sits and what you can change without the other side agreeing. The same choice for a company site with no basket is settled on different criteria, and has its own piece on WordPress vs a custom website.

The six criteria side by side

What exactly can you export when you decide to leave

The question is not “is there an export” but “what exactly does it cover, and in what format”. Almost every platform will hand back products, categories, customers and orders in a CSV or XML file or through an API — that is the easy part.

The rest of the catalogue is harder, because every platform keeps it in its own structure:

• images at original resolution, not the thumbnails the template generated,
• variants, attributes and the relationships between them (size, colour, per-variant availability),
• descriptions with HTML formatting, spec tables and embedded media,
• customer reviews with their dates and product assignment,
• coupons, discount rules and loyalty programme balances,
• static page content, terms and conditions, and blog posts,
• the full list of existing URLs, including discontinued products.

Customer passwords never move — they are stored as hashes, so after a migration customers set them again. Plan that into your communications; in practice it is the change buyers notice most.

An answer of “we will write a script when the time comes” is a negative answer. A useful answer names the data sets and the formats, and it can be written into the contract.

Who controls the URL structure and the structured data

In a custom store you define the URL pattern and the structured data markup in the template; in a hosted one you get whatever the vendor exposes in the settings. The difference only shows up at the first significant change to the information architecture.

Four things to check in the panel before you consider the subject closed: whether you can change the URL pattern for categories and products without raising a ticket; whether filter combinations generate separate URLs and whether you can control them with a canonical tag and exclusion from indexing; whether you can add your own fields to product and offer structured data; and whether the panel lets you set permanent redirects for addresses that no longer exist.

Any change to the URL pattern after launch is a separate operation, planned the way you plan a website migration without losing rankings, not the way you flip a setting in a panel.

Does the template meet level AA out of the box

No vendor can declare on your behalf that your store is accessible — conformance depends on the template, the plugins, the content you type in and the scripts you paste on. A template can be a good starting point or a bad one, but on its own it does not close the subject.

The practical criterion is different from a marketing claim: check how much you can fix yourself. Walk the whole checkout path using the keyboard alone, at 200 percent page zoom, and watch the focus outline, the field labels in the order form, validation error messages, how filters behave, and how the store signals that a product went into the basket. Then work out which of those you can change in the template and which need a ticket to the vendor.

The requirements for e-commerce come from Directive (EU) 2019/882, applicable from 28 June 2025, and the detail — including the microenterprise exemption and EN 301 549 pointing to WCAG at level AA — is covered in the piece on website accessibility under the European Accessibility Act. This material is informational and is not legal advice.

Categories with filters: where the store starts to slow down

Responsiveness to interaction usually breaks not on the home page but on a category with many products and filters switched on. Every click on a filter fires a query with several conditions, recalculates the counts next to the remaining filter values and repaints the list with its images — all while the user waits for a response.

In the hosted model you have no influence on how the vendor computes facets; you do have influence on the number of filters, the number of products per page and the weight of the product card. In the custom model this part can be redesigned — for example by moving search and filtering into a separate index, so the order database is not answering catalogue queries.

There is no sensible benchmark saying “platform A is faster than platform B”, because the result depends on the catalogue, the template, the number of external scripts and the hosting. Measure on your own densest category, on a mobile device. The metric thresholds, and the fact that the assessment is built from CrUX field data over a rolling 28-day window at the 75th percentile, are covered in the article on Core Web Vitals.

Who is responsible for security updates

In the hosted model the vendor patches the engine and the server; in a custom build it is the shop owner or the supplier under a maintenance agreement. That is a real difference in workload, but it is not a complete split — part of the responsibility stays with you whichever model you run.

Always yours: staff accounts and permissions, integration keys and tokens, third-party scripts pasted into the template, modules installed from external sources, and your obligations as a data controller. An engine update is also a common moment for inventory synchronisation to stop working — which is why, where integrations exist, you ask not only who applies updates but who tests after them.

The cost of leaving: count time and risk, not the monthly fee

The cost of leaving is the sum of the work needed to run the store somewhere else without losing data, URLs or sales during the move. The subscription is the smallest and easiest item in that sum, so it is not the one that decides.

The real items are: mapping and verifying the catalogue with its variants, moving the media, rebuilding order history and customer accounts, a complete list of redirects from old addresses, reimplementing payments and shipping, reconnecting the warehouse and accounting systems, testing the checkout path, and the support team’s time while two systems run in parallel. Then there is the risk: the less complete the export, the more manual work, and the higher the chance something disappears quietly.

You do this arithmetic once, ideally before choosing a platform rather than after three years. What it needs is an orderly description of the catalogue, the integrations and the development plan — tell us what the store has to do and that description is where the conversation starts. The result is often counter-intuitive: a store that costs more month to month can be cheaper over three years because it generates almost no exit cost, and a cheap launch can turn into the most expensive line item in the year you have to move.