When a General Site Builder Is the Wrong Place for a Store
Somewhere in the last decade, the website builder became the default answer to every small business question. Need a portfolio? Builder. Need a booking page? Builder. Need a store that sells physical goods, collects tax, calculates shipping, and handles a return? The same builder gets recommended, usually by someone who has never shipped a box. That is where the trouble starts, and it is not a small trouble.
The general site builder is a genuine marvel of the modern web. It lets a person with no code and no budget put a decent-looking page online in an afternoon. For a bakery posting hours, a consultant writing a bio, a band listing tour dates, it is close to perfect. The problem is that a store is not a page with a cart bolted on. A store is a small, loud, constantly moving business, and the general builder was never designed to run one.
What follows is not a knock on any particular brand. It is an argument about category, and the category mismatch is real enough that plenty of store owners discover it only after they have already paid for a year of hosting and built two hundred product pages.
The page builder's job description ends where selling begins
A general site builder is optimized for presentation. Its core talent is arranging blocks of text and image on a canvas so the result looks deliberate on a phone and a laptop. Its data model is thin: a page has sections, a section has content, and content is mostly text and pictures. That model is wonderful for a brochure and awkward for a catalog.
A store needs something else entirely. It needs a product to exist as a record, with a price, a stock count, variants, weight, dimensions, and a tax category. It needs that record to appear in a grid, in a search result, in a cart, in an order, in a refund. A page builder sees a product as a pretty tile. Commerce software sees a product as an object with a life cycle.
That difference sounds abstract until the first time a shop owner needs to change a price across forty items, or hide a sold-out size, or export a list of orders for an accountant. On a general builder, these jobs turn into manual labor, one page at a time.
Inventory that lives in a spreadsheet is inventory that drifts
The most common workaround is a plugin or a lightweight add-on that turns a page builder into something store-ish. It usually works at first, when there are twelve products and no returns. Then the shop grows. A second sales channel appears, maybe a market stall or a wholesale account. Someone sells the last large hoodie at a weekend fair and forgets to update the site. Two customers buy it online the same evening.
Now the owner is writing apology emails and refunding payments, and the cause is structural. The builder was never keeping a single authoritative count of anything. Stock lived in a spreadsheet, the spreadsheet lived in someone's head, and the website was a photograph of the spreadsheet from last Tuesday. Commerce platforms treat inventory as the spine of the whole operation. General builders treat it as a field on a page.
Shipping math has a way of exposing the cart
Ask anyone who has run a small shop what ate their first year of profit and the answer is often shipping. A general builder's cart tends to offer blunt options: flat rate, free over a threshold, maybe a rough weight table if a plugin provides one. Real shipping is a knot of zones, carrier services, dimensional weight, and the quiet insult of a box that costs more to send than the item inside it is worth.
Commerce software connects to carriers, pulls live rates, and lets a shop set rules per region and per service level. A general builder makes the owner guess, and guessing produces two failures at once. Guess low and the shop eats the difference on every order. Guess high and the cart looks expensive next to a competitor whose rates are accurate to the penny.
There is a smaller, sharper version of this problem too. A builder's checkout often cannot split a shipment, handle a preorder alongside an in-stock item, or apply a discount to one product and not another without a stack of add-ons that were never tested together. Each of those gaps is survivable alone. Together they turn checkout into a place where orders quietly die.
The tax question arrives before the first sale
Sales tax used to be a local worry. It is now a geography problem. Once a shop crosses a threshold in another state or country, it owes tax there, at that jurisdiction's rates, on the right categories of goods. A general site builder will happily collect a single rate the owner typed in by hand. It will not track nexus, will not update rates when a city changes them mid-year, and will not produce the kind of report an accountant can reconcile without a weekend of work.
This is the point where the mismatch stops being annoying and becomes expensive. A store that under-collects owes money it never charged. A store that over-collects has to refund customers and explain itself. Neither outcome is the builder's fault in any moral sense. The builder simply was not built to know that tax is a moving target tied to where a buyer lives.
A cart that cannot recover an abandoned checkout is leaving money on the table
Most carts are abandoned. That is not a failure of the shop; it is the ordinary behavior of people shopping on phones with a toddler on one hip and a meeting starting in four minutes. The stores that survive this behavior are the ones that can nudge: a reminder email an hour later, a second one the next day, a small discount for the person who stalled at the shipping page.
Recovery flows live inside commerce platforms as a first-class feature, wired to order data and customer records. On a general builder they are an add-on, sometimes a paid one, and the data they depend on is often split across plugins that do not share a vocabulary. The shop owner ends up exporting a list and emailing it manually, which is exactly the kind of work that gets skipped in a busy week. The abandoned carts do not care. They keep stacking up.
Product pages that cannot say what a buyer needs to know
Consider a shop selling one thing well: wool socks. The buyer wants to know the fiber blend, the care instructions, the fit across three sizes, whether the heel is reinforced, and what the return window is. A commerce platform gives each of those its own structured field, so the page renders a clean size chart and a care block and a return policy without anyone hand-building it per product.
A general builder gives a text box. The owner types the details into the description, formats them by eye, and repeats that labor for every product. When a policy changes, the owner edits every page. When a new size is added, the owner edits every page. The work multiplies against the catalog, and the catalog is the thing that is supposed to grow.
There is a subtler cost buried here. Structured product data is what lets a store show up properly in search results and shopping feeds, with price and availability attached. A page built by hand from text blocks tends to produce a handsome page that search engines struggle to interpret as a product. The shop looks fine to a human and invisible to the machine that sends humans.
Where the general builder genuinely wins
None of this means the general builder is bad. It means it is being asked to do a job outside its design. Plenty of small operations are honestly served by one. A maker selling six items at craft fairs, taking orders by email, and shipping twice a week does not need a commerce stack. A photographer selling prints in three sizes might be fine. A restaurant with a menu page and a deposit link is not running a store at all.
The builder's real advantage is speed and cost at the very beginning. A person can be live in a day for the price of a lunch. That advantage is real, and it is worth naming plainly rather than pretending every shop must start on a full platform.
The trouble is timing. The moment a shop adds a second channel, a return policy with teeth, a tax obligation in another state, or a catalog past a few dozen items, the builder's advantage inverts into a tax on the owner's hours. The migration that follows is never cheap. Product pages get rebuilt, order history gets exported in a format nobody loves, and links break in ways that cost search rankings.
The migration bill arrives later, and it is larger
Owners tend to evaluate the builder on the day they sign up, when the price is low and the demo is smooth. The honest comparison happens two years in, when the shop has three hundred products, a wholesale account, a returns process, and a bookkeeper asking for quarterly tax reports. At that point the question is not which tool is cheaper. It is which tool has been keeping the shop's records in a form the shop can actually use.
A commerce platform costs more per month and asks more setup on day one. It also keeps products, orders, customers, and tax in one place, so the shop can grow without the owner rebuilding the foundation every eighteen months. That is the trade: pay a little more now for a structure that holds, or pay less now and pay again, in hours and lost orders, when the structure gives way.
The clearest signal is a simple question. If the shop doubled its catalog and added a second sales channel next month, would the current setup absorb that, or would it creak? A general builder is the right home for a page. A store is a business with a memory, and it needs a home built to remember.
