What it actually costs to run an online store

Build cost gets scrutinised. Running cost rarely does, and it is the larger number over any meaningful period. This is the full list, including the parts that accumulate without anyone deciding to let them.

The cost lines

Platform

On a hosted platform this is the monthly subscription, and it is the most predictable line on the list. Plan tiers usually change what you can do rather than how much traffic you can take.

On a self-hosted platform there is no licence, but see hosting below.

Payment processing

Usually the largest variable cost, and it scales directly with success. Two components: the processor’s percentage and fixed fee, and on some platforms an additional platform fee unless you use their own payment product.

That platform fee is worth calculating properly rather than dismissing. On a store doing meaningful volume it is a substantial annual number, and it is the main financial argument for self-hosted platforms.

Apps and extensions

This is the line that grows quietly, and the one we most often find has never been reviewed.

The pattern is consistent. A store adds an app to solve a real problem. The problem passes, or the feature gets built into the platform, and the app stays. Repeat a dozen times over two years and you have a monthly total nobody chose.

There is a second cost too. Every app that injects a script adds render-blocking weight to every page, including pages where it does nothing. So the subscription total understates the real cost.

Audit the list twice a year. It is routinely the fastest saving available on a store, and it usually improves performance at the same time.

Hosting

Zero on hosted platforms. Real and growing on self-hosted ones, where you need enough capacity for object caching, a staging environment and backups — which rules out the cheapest tiers.

Budgeting the minimum here is a false economy that produces the slow-store problem covered in running WooCommerce properly.

Domain, email and certificates

Small, annual, and universally forgotten until renewal. Business email at per-seat pricing adds up on a growing team.

Transactional messaging

Order confirmations, shipping notices, password resets, abandoned-cart sequences. Free tiers cover early volume, then stop. Stores typically discover this during a busy month, which is the worst time to be reconfiguring an email provider.

Maintenance

On self-hosted platforms, someone must apply updates, test them, and keep backups. Whether that is a retainer or in-house time, it is a real recurring cost and pretending otherwise is how stores end up unmaintained.

Development

Stores change. New products, seasonal content, a checkout fix, a campaign landing page, an integration with a system the business just adopted.

Businesses that budget nothing for this end up with a store frozen at its launch state, slowly diverging from how the business actually trades. The cost of not changing is invisible and larger than the cost of changing.

The three-year convergence

Hosted platforms are cheaper in year one. The gap narrows every year, because app subscriptions accumulate while self-hosted extension costs are often one-off licences.

Self-hosted platforms cost more to set up properly and stay flatter, provided somebody owns maintenance. If nobody does, the eventual cost is a security incident, which is not a line item anyone budgets for.

Over three years the totals land closer together than either camp claims. Choose on fit and maintenance capacity, not on a cost comparison that only counts one column.

Three worked examples

Illustrative shapes rather than real client figures, to show how the balance shifts as a store grows.

A new store, first year

Platform subscription on an entry tier. Payment processing on modest volume. Three or four apps, chosen carefully. A domain and one business email seat. Transactional email comfortably inside a free tier.

The dominant costs are not on this list. They are photography, initial content, and whatever brings the first traffic. Store running costs at this stage are genuinely small, and the common mistake is over-investing in tooling before there is anything to tool.

An established store, steady trade

Platform subscription, possibly on a higher tier. Payment processing now a substantial monthly number. Eight to fifteen apps, several of which nobody has reviewed since installing. Transactional email now paid. A developer engaged periodically for changes.

This is where the app audit pays for itself. It is also where development budget starts mattering, because the store now needs to change regularly and every change that requires a quote is a change that gets deferred.

A growing store, multiple markets

Higher platform tier or Plus. Payment processing across currencies with additional fees. A larger app stack, plus at least one genuinely expensive specialist tool. Meaningful transactional volume. Either a retainer or an in-house hire, because ad-hoc development no longer keeps up.

Costs are now dominated by people rather than software. The subscriptions are noise against the development and operational spend, which is a different budgeting conversation entirely.

Costs that scale, and costs that do not

Useful when forecasting, because they behave very differently.

Scales with revenue: payment processing, transactional messaging volume, hosting on a self-hosted store, some usage-priced apps.

Scales with complexity: development time, integrations, the number of templates and markets to maintain.

Scales with neglect: technical debt, an unaudited app stack, deferred updates. This category is invisible until it is expensive.

Fixed regardless: platform subscription, domain, certificates, most app subscriptions.

The third category is the one to watch, because nothing on a dashboard reports it. A store that has not been maintained for two years has a real, accumulating cost that appears all at once when something finally breaks.

The subscription audit, step by step

Half a day, twice a year, and it is the highest-return administrative task available on a store.

1. List every recurring charge, including anything on a personal card or a departmental budget. Check the payment provider statement rather than relying on memory.
2. For each, answer: what does it do, when did we last use it, has the platform since built this in, and does it inject a script on every page?
3. Cancel anything that fails all four. There is usually more than you expect.
4. Check what removal leaves behind. Uninstalled apps frequently leave code in the theme — detail in the apps slowing your store.
5. Measure the store before and after. Both the monthly total and the page weight.
6. Write down what remains and why, so the next audit starts from a list rather than from scratch.

Most stores that have never done this find both money and speed in the same afternoon, which is a rare combination in this line of work.

Project or retainer?

For continuous small work, a retainer is usually better value — each separate project carries scoping and context-switching overhead that a retainer absorbs.

For a single defined piece of work with a clear end, a project quote is better. The deciding factor is not size, it is whether the work is continuous or finite.

Our own answer to this is ProNuts, published at a real monthly price rather than “contact us for pricing”, with the exclusions listed openly. If your need is one defined project, we will quote it as a project instead.

A budgeting exercise

List every recurring charge against the store. Include the ones on someone’s personal card. For each, answer:

1. What does this do?
2. When did we last use it?
3. Has the platform since built this in?
4. Does it inject a script on every page?

On most stores, that exercise finds money and speed in the same afternoon.

Costs outside this list

Deliberately excluded above because they are not store running costs, but they consume the same budget and are worth naming so the picture is complete.

Photography. The most consistently underinvested line in ecommerce. Product pages fail more often on missing information and poor imagery than on anything technical, and good photography outperforms most development work per pound spent.

Content. Product descriptions, category copy, editorial. Someone has to write it, and “we’ll do it internally” usually means it does not happen.

Marketing. Paid acquisition, email, affiliates. Frequently the largest number in the whole business, and entirely outside this article.

Fulfilment and returns. Packaging, postage, warehousing, and the cost of goods coming back. In some categories returns are the difference between profit and loss.

Customer support. Whether that is somebody’s time or a dedicated person.

We separate these because store running costs get conflated with the cost of running a business, and the conflation makes the technology look either cheap or ruinous depending on which side of the line you draw it.

Reducing what you spend

In rough order of return.

Audit the subscriptions. Covered above. Fastest win available, and it improves speed at the same time.

Consolidate overlapping tools. Most stores run two things that do the same job because each was added to solve a specific problem at a different time.

Check your payment processing rate. Rates are negotiable at volume and most merchants never ask. This is a phone call, and on a store doing real numbers it is a meaningful annual saving.

Move recurring work into automation where the payback is clear — see what to automate first.

Fix things properly rather than repeatedly. A recurring manual workaround has a cost that never appears on any invoice, and it usually exceeds the cost of fixing whatever causes it.

Do not economise on hosting if you are self-hosted. It is the one line where spending less reliably costs more, in performance, in incidents, and eventually in an emergency migration.

A budgeting template

For an annual review, list against each line: what you pay, whether it scales with revenue, when you last reviewed it, and what would happen if you removed it.

That last column is the useful one. Anything where the honest answer is “nothing much” has been identified, and anything where the answer is “the store stops” is not a candidate for cutting regardless of cost.

The one habit worth adopting

Put a recurring reminder in the calendar, twice a year, to review every subscription against the store.

That single habit prevents the most common cost problem in ecommerce, which is not any individual expensive tool. It is the slow accumulation of a dozen small ones that each made sense at the time, that nobody has revisited, and that collectively cost more than anybody realises while making the store measurably slower.

Half a day, twice a year. It is the highest-return administrative task available to a store owner.

A closing note

The most expensive line on any store is rarely the one anybody worries about. It is the accumulated cost of small decisions nobody revisited — the app installed for a campaign that ended, the plan tier upgraded for a feature never used, the maintenance deferred until it became an incident.

None of those appear on a budget as a problem. All of them appear eventually as a number.

Where the money usually is

Two things, on nearly every store we audit.

An app or extension stack that has never been reviewed as a set, costing more than anyone realises and slowing the store while it does it. And a payment processing rate that was agreed when the business was much smaller and has never been renegotiated since.

Neither requires development work to address. Both are worth more than most optimisation projects.