Ecommerce Websites: The Parts You Pay For Every Month

An ecommerce website is not one thing. It is a catalogue, a cart, a payment integration, an order system, a fulfilment process and a customer-account layer, wearing one coat — and the monthly bill is the sum of those parts rather than a hosting line.

Most guides compare platforms. That is the second question. The first is understanding which of these parts you actually need on day one, because the difference between a store that costs a few pounds a month and one that costs a few hundred is mostly a matter of how many of them you switched on before you had customers.

Table of contents

• The six parts, and which you can skip
• Where the money actually goes
• Hosted platform, self-hosted, or headless
• The things that actually convert
• A sensible order to build in
• How this fits the rest of the stack
• FAQ

The six parts, and which you can skip

1. The catalogue. Products, variants, prices, images, stock. Unavoidable. The thing that makes it expensive is variants — one product in five sizes and four colours is twenty stock records, and getting that model wrong early is painful to unpick.
2. The cart and checkout. Where money is won and lost. Every additional field loses customers. The single highest-return change most stores can make is removing steps.
3. Payments. A processor, and you are handling card data by reference rather than directly if you have any sense. Unavoidable.
4. Order management. What was bought, by whom, what state it is in, what happened next. Can start as email plus a spreadsheet, genuinely, and many stores do.
5. Fulfilment. Picking, packing, shipping, tracking, returns. Mostly a physical process rather than software at low volume.
6. Customer accounts. Order history, saved addresses, wishlists. Skippable at the start — guest checkout converts better anyway, and accounts add a password-reset flow, a data-protection obligation and a support burden.

The last point is worth dwelling on because it inverts the usual instinct. Requiring account creation before purchase is one of the most reliable ways to lose sales. Offer accounts later, to people who already bought.

Where the money actually goes

Ordered by how much it typically is, which is not the order people expect.

• Payment processing — a percentage of every transaction plus a fixed fee. At any real volume this dwarfs every other line on this list, and it scales directly with success. Worth understanding precisely rather than approximately.
• Platform fees — a monthly subscription and, on some platforms, an additional cut of sales. This is the line to check for a transaction percentage hiding underneath the headline price.
• Apps and plugins — the one that creeps. Each is small; a store running fifteen has a substantial monthly total that nobody decided on in one go. Audit these twice a year.
• Hosting — usually one of the smaller lines, and highly dependent on shape. A store needs a runtime and a database on continuously, which is a real cost, but it is not where the money goes.
• Bandwidth and images — a product catalogue is image-heavy. The same resize-and-modern-format discipline that applies to a portfolio applies here, and it is the cheapest performance win available.
• Email — transactional (receipts, shipping) and marketing. Transactional is small and non-negotiable; marketing scales with list size.

The strategic point: payment processing is proportional to revenue and largely fixed by the market, while everything else is a decision. Optimising the small lines while ignoring an unnecessary transaction percentage on the platform fee is a common and expensive mistake.

Hosted platform, self-hosted, or headless

Three shapes with genuinely different trade-offs.

A hosted platform runs everything. Fastest to launch, no maintenance, and you accept the subscription, any transaction cut, and the fact that the store is not portable. Correct for most people starting out — the operational simplicity is worth a great deal when you are also learning to sell.

Self-hosted ecommerce software gives you the code, the database and the ability to change anything. It also gives you the obligation: updates, backups, security, performance, and a payment integration that must not break. Real, and heavier than the enthusiasts suggest, particularly because a store outage costs money directly.

Headless separates the storefront from the commerce backend, letting you build any front end against an API. Genuinely powerful, and it is a developer-team architecture rather than a small-store one. Choosing it early usually means building infrastructure instead of selling.

The honest recommendation: start hosted unless you have a specific reason not to, and revisit once you have enough revenue that a percentage point of it pays for engineering time.

The things that actually convert

Independent of platform, these move revenue more than the technology choice does.

• Fast product pages on a phone. Most traffic is mobile and a slow page loses buyers before they see the price. This is mostly image optimisation.
• Guest checkout. Forcing account creation is a reliable way to lose a meaningful share of ready buyers.
• Shipping cost shown early. Unexpected shipping at the final step is the most cited reason for cart abandonment, by a wide margin. Show it on the product page or state a clear threshold.
• Real photographs from several angles, plus scale. Returns fall when people knew what they were getting.
• A visible, generous returns policy. It increases purchases more than it increases returns, because it removes the risk from the decision.
• Working transactional email. Receipts and shipping notifications that arrive. Broken order emails generate support tickets and destroy trust faster than almost anything else.

None of these are platform features to buy. They are decisions, and they are available on any setup.

A sensible order to build in

1. Register the domain and check the name across the channels you will use.
2. Get one product listed, photographed properly, with a working checkout — end to end, including a real test purchase with a real card that you then refund.
3. Verify receipts and shipping emails actually arrive, to more than one provider.
4. Add the rest of the catalogue once the flow works.
5. Add analytics and watch where people drop out, rather than guessing.
6. Add accounts, wishlists, reviews and the rest only when customers ask or the numbers justify them.

The test purchase in step two is the one people skip and the one that catches the most. A store that has never processed a real transaction has an unknown number of broken steps in it.

How this fits the rest of the stack

Unlike a brochure site, a store needs a runtime and a database running continuously, and that is a predictable monthly line worth knowing before you pick a shape. The RunxBuild hosting calculator puts the service, the database, the storage and the bandwidth together so the figure is explicit. RunxBuild runs the application layer — Node, Next.js, Python, Go, Ruby, Java, .NET and Docker deployed from a repository — with managed MySQL or Postgres alongside on private networking, and autoscaling between a floor and ceiling plan for the days a product takes off.

Useful related references:

• Python for Websites: Where It Fits and Where It Does Not
• Photography Hosting: What Image-Heavy Sites Actually Need
• Dynamic Websites vs Static Sites: The Server, the Cache, the Data, and the Right Choice for 2026
• Services on RunxBuild

FAQ

What does an ecommerce website consist of?

Six parts: a catalogue, a cart and checkout, payments, order management, fulfilment, and customer accounts. Only the first three are unavoidable at the start — order management can begin as email plus a spreadsheet, and customer accounts are genuinely skippable since guest checkout converts better.

Where does the money go on an ecommerce site?

Payment processing first, by a wide margin at any real volume, since it is a percentage of every transaction. Then platform fees, then apps and plugins which creep without anyone deciding. Hosting is usually one of the smaller lines. Optimising hosting while ignoring a transaction percentage is a common expensive mistake.

Should I use a hosted ecommerce platform or self-host?

Start hosted unless you have a specific reason not to. The operational simplicity is worth a lot while you are learning to sell, and a store outage costs money directly. Revisit when revenue is high enough that a percentage point of it pays for engineering time.

Why do people abandon carts?

Unexpected shipping cost at the final step is the most cited reason by a wide margin, followed by forced account creation. Both are decisions rather than platform limitations — show shipping early or state a clear free-delivery threshold, and offer guest checkout.

What should I test before launching a store?

One product, end to end, with a real card that you then refund — and confirm the receipt and shipping emails actually arrive at more than one email provider. A store that has never processed a real transaction has an unknown number of broken steps in it.