What an Online Store Builder Has to Handle Before You Sell

What an online store builder actually has to handle

Eight jobs decide whether a builder is usable for your catalog. Every feature list is these eight with different names on them.

• Catalog and options. Products, variants, images, descriptions, and the options that change price or availability.
• Checkout and payment. Guest checkout, cards, wallets, invoice or bank transfer, and the fees attached to each.
• Tax and shipping. Rates by destination, thresholds, delivery options, and who calculates what.
• Fulfilment. Stock, packing, part-shipments, and what the buyer is told at each step.
• Returns and refunds. What the buyer can request, what you approve, and how the money moves back.
• Records. Invoices, order history, statements and exports your accountant can use.
• Content around the products. The category and guide pages that bring buyers in before they shop.
• The operator side. Staff accounts, permissions, reporting and an audit trail.

The catalog is where stores quietly break

A product with options is where cheap builders fail, because options are not products. If the same item comes in four sizes, the builder has to model one product with four options that carry their own price and stock — not four separate products the buyer has to decipher.

The catalog also has to cope with sales where the thing sold is not a box on a shelf:

• A seat at a dated event, with a section, a row and a check-in.
• A rental, where availability by date is the product.
• A digital file, where there is no stock but there is a download and a licence.
• A subscription, where the order repeats and can pause.
• A bundle, where components come out of stock together.

Checkout: the three places the sale is lost

Buyers abandon a checkout for three reasons a store can control: a cost that appears for the first time at the last step, a forced account creation before payment, and a payment method the buyer does not have or does not trust.

Everything else is speed. The checkout has to work on a phone, in a browser the buyer did not choose, with a card they are typing in public. If the builder cannot do guest checkout, cannot show shipping before the payment step, or loses the cart when the buyer switches apps to find their card, the rest of the store does not matter.

Where should you sell? A plain comparison

Four routes cover almost every small business, and they differ mainly in what you keep after the sale.

• A store on your own domain. You control the catalog, pricing, checkout, customer list and brand; you do not control traffic, hosting or maintenance.
• A marketplace. You control the listing and the price; the platform controls fees, ranking, buyer data and the rules.
• Social messages and comment selling. You control the conversation and the speed; you give up clean payment records, a searchable catalog and repeat-purchase data.
• A vertical platform for a specific sale type (ticketed events, auctions, timed drops). You control stock and price; the platform decides how the sale runs.

Fees, tax and payouts: model the take rate first

Builders are priced in three ways: a flat subscription, a subscription plus a fee per transaction, or software you host and pay for yourself in hosting and maintenance. The three-year total decides which is cheapest, and it is rarely the plan with the lowest headline number.

Two lines do most of the work. The first is the take rate: what share of each order leaves as platform and payment fees, and whether that applies to the shipping and tax lines too. The second is tax: whether the builder calculates destination-based tax and produces records your accountant can file from, or whether that job stays with you.

• Ask what happens to fees when an order is refunded — many platforms keep the original cut.
• Ask when payouts land and what happens when a buyer disputes a charge.
• Ask whether orders and customers export in full, including historical ones.

What you should own when you leave

Product data, customers, order history and content are the parts of a store that carry value, so the export test belongs at the start rather than at the end: ask for a full export before you sign. A builder that returns a catalog but not the customer and order history is renting you a business rather than helping you build one.

The migration itself

A migration is a data job with a deadline, and the failures are predictable: options that lose their prices, order states that do not map, and old product URLs that dead-end in search results.

• Export the catalog with options, images and descriptions, then check that the option prices survived.
• Map order states from the old system to the new one before moving any orders.
• Redirect old product and category URLs to their new equivalents.
• Run one real end-to-end order on the new store, refund included, before you announce it.
• Keep the old store reachable until the new one has taken a live order.

Where ShopDango fits

ShopDango builds stores where the sale is not always a simple product: retail items sit alongside ticketed events, auctions, equipment rentals, subscriptions and digital goods, with one catalog, one checkout and one console for the operator. That combination is usually the point at which a general-purpose store builder runs out of options.

If your sales are plain retail and only plain retail, any competent builder will do. The check that matters is the one your catalog fails first.