Platform arguments are usually identity arguments. The three-year total is the only comparison that is not — including the app subscriptions nobody counts and the transaction fees everybody forgets.
Ask which platform is best and you will get answers with remarkable confidence behind them. Most of those answers are about identity rather than commerce: people defend the tool they know how to use, and each camp has a real argument, which is what makes the discussion so durable and so useless.
There is one comparison that cannot be argued with, and almost nobody runs it: what does each option cost over three years, and what does your business actually look like. We sell custom development, so read the section where we say a hosted platform wins — it is the part that costs us money.
Add those up for each option before you argue about anything else. Half the time the decision stops being interesting at this point, which is the best possible outcome.
A standard catalogue, a small team, nobody technical on staff, and a need to be selling this quarter. In that shape a hosted platform is not the compromise — it is the correct answer, and paying for custom work would be an expensive way to buy features you already have.
It also wins in a case people underestimate: when the store is not the differentiator. If your advantage is the product, the photography, the brand or the relationships, then the machinery should be boring and cheap so the money can go where the advantage is. We have talked several clients out of custom builds on exactly this basis.
When you already run a serious content operation and the store is one part of a larger publishing effort, keeping both in one system removes a whole category of friction. It also wins when your product logic is unusual but still within reach of existing extensions, and when there is somebody technical nearby — an in-house developer, an agency on a real retainer, a capable freelancer who answers.
The condition is that last part. This route rewards having maintenance capacity and punishes not having it, which is the mechanism behind most of the horror stories: not the software, the absence of anybody looking after it.
Four shapes, all of them business shapes rather than technical preferences.
The experience itself is the product — configurators, quoting logic, subscription rules no plugin imagines, a buying process that is your competitive advantage rather than a step. Integrations that off-the-shelf tools were never designed for: an old warehouse system, industry pricing rules, a partner network. Scale where platform percentages have grown past the cost of engineers, at which point custom is the cheaper option and the conversation is arithmetic. And a product rather than a store: accounts, permissions, recurring billing, an admin your team lives in all day.
If your growth plan is “sell more of the same catalogue on the same site”, none of these apply — you have a conversion and speed problem, which is a tenth of the price to fix. Our three-year math on headless commerce makes the same point with numbers attached.
The app ecosystem is the strongest feature of hosted platforms and the least examined cost in this comparison. Every app is three things at once: a subscription, a dependency and a performance charge. The subscription is visible. The dependency shows up when a vendor is acquired, raises prices or stops updating. The performance charge shows up in your conversion rate, quietly, because most apps add scripts to the pages where people are trying to buy.
Count your apps once a quarter and price them as a bundle. Then price what they do to your speed — the third-party tax is how we translate that into money per order. Stores that do this exercise routinely remove a third of their apps and get faster and cheaper in the same afternoon.
Three mistakes turn up in almost every comparison we are asked to review.
The first is comparing build prices and nothing else, which is comparing the smallest line over three years. The second is forgetting the work that has no vendor attached: moving products, images, customers and order history, writing the descriptions, photographing what has never been photographed properly. That work exists regardless of platform and it is frequently the largest single effort in the project.
The third is subtler. People compare each option against their current pain rather than against their intended future. Anything looks good next to a store you already hate. Write down what the business needs to be doing in two years — more markets, subscriptions, a second brand, wholesale pricing — and compare against that instead, because that is the version you will be running when the migration decision arrives.
Put your own numbers in; the shape is the point. Take each option and fill in six lines: build, platform fee times thirty-six, apps times thirty-six, transaction percentage against your realistic annual revenue, engineering hours per year times three, and a rough figure for leaving in year three.
Two things usually surface. Percentages dominate at higher revenue, so the option that looked expensive to build becomes the cheap one somewhere between “nice side business” and “this is the business” — and knowing roughly where that line sits for you is more useful than any opinion about software. And the app column is bigger than expected in almost every case, because it grows quietly, one small justified subscription at a time.
Leaving a hosted platform with a plain catalogue is straightforward. Leaving after you have built your operations inside a dozen apps — your subscriptions, your loyalty scheme, your fulfilment rules — is a project, because the logic lives in tools that do not export it.
That is not an argument against starting there. It is an argument for knowing which decisions are hard to reverse, and for keeping the two things that make any migration survivable: your product and customer data in a form you can export, and your accounts in your own name.
Ask what your store has to do in three years that it cannot do today, then ask which option gets you there without a rebuild. Most businesses discover the honest answer is “nothing exotic”, and the right choice becomes the cheapest one that does not trap them.
The stack should be the least interesting thing about your store. No customer has ever asked what ours runs on. They notice that pages arrive instantly and that paying is painless — spend accordingly.