Running costs of an online store after launch

The build quote for a shop gets studied carefully. Proposals are compared, stages are negotiated, everyone checks what is included in the price. Then the shop launches, and invoices start arriving that were never in that quote.

A shop is an asset with a running cost, and that cost is predictable if you calculate it in advance.

Invoices that were not in the plan

Development is budgeted as a project with a beginning and an end. Running costs work differently. They have no end and do not depend on whether you sold anything this month.

Hosting or a server

The first line everyone remembers, and at the same time the one most often underestimated. At launch a shop runs fine on a basic hosting plan. A year later the catalog has grown, price imports and background jobs have been added, and the plan starts hitting its limits.

• Shared hosting. The cheapest option, suitable for a shop with a small catalog and steady traffic.
• A virtual server. Needed once background jobs, a queue or separate services appear. On top of the rent there is usually server setup and administration.
• Off-site backup storage. Backups must be kept away from the server itself, and that is a separate invoice.

Which of these items a given plan covers and which it leaves to you is the subject of our article on how to choose hosting.

Domain and certificate

A small thing that regularly ruins somebody’s week. The domain renews once a year, the certificate more often, and both have a habit of expiring at the worst moment.

The danger is that the reminder goes to a mailbox nobody checks. When a domain is not renewed the shop disappears from the internet entirely, and restoring it takes anywhere from a few hours to several days depending on the registrar.

Paid modules and licenses

A shop is rarely just the platform. Modules are added on top, and almost every one has its own subscription.

• Payments. A commission on every order plus, sometimes, a monthly fee for the service.
• Delivery. Cost and status calculation, often through a separate service with its own pricing.
• Catalog search. The built-in one is free, an external engine is paid, and the difference is noticeable on catalogs of several thousand items.
• The theme. Some commercial themes come with a yearly license. Without a renewal, the theme keeps working but stops getting updates. On ThemeForest, updates have no time limit, and you pay only to extend the author’s support if you need it.
• Accounting integration. The module that syncs with your accounting system usually has its own subscription.

Each line is small, and together they add up to a noticeable total. Count them before launch, at the point where you are still choosing what to install. The list of modules is shaped during e-commerce website development, when the platform and the set of integrations are chosen.

It is also worth looking at modules that were installed at some point and then fell out of use. They keep updating, take up space, sometimes slow the admin panel down, and the invoice for them keeps coming. Once a year it pays to go down the list and switch off whatever nobody uses.

Updates and security

Why updates cannot be skipped

The platform, the modules and the language everything runs on are updated constantly. Some updates add features, some close vulnerabilities. A shop that has not been updated for a year works perfectly well right up until the day it does not.

The risk here is not abstract. A shop takes payments and stores customer contacts, so it draws more attention from attackers than a page describing services. A compromised shop means not only downtime but a conversation with customers about what happened to their data.

• Platform updates. Planned work with a backup beforehand and a check afterwards.
• Module updates. This is where vulnerabilities appear most often, because there are many modules and different people write them.
• The PHP version. An outdated one sooner or later stops receiving security fixes.
• File permission checks. After every major update, check what changed.

The backup check nobody runs

Backups are created on a schedule, and that is exactly why people stop thinking about them. The file is there, it takes up space, the box is checked. The question is whether a shop can be brought back from it, and the answer usually emerges on the worst possible day.

The check itself is cheap. Once a quarter take a fresh archive, restore it to a test environment and look at three things: does the catalog open, are the latest orders in the admin panel, does the administrator login work. An hour of work, and you know for certain that the insurance is real.

The second thing to check is recovery time. Twenty minutes of downtime costs one or two orders. Half a working day of it costs a day of sales and some of the trust of everyone who could not pay in that window. The difference is easy to price, so it is worth knowing your recovery time in advance rather than discovering it during an incident.

Small fixes and seasonal work

This is the line nobody puts in the quote, and it appears every month. Some of these tasks arise because the shop is alive: products are added, terms change, new partners appear. Some arise because any complex system gradually accumulates small gaps between how it was designed and how it is actually used.

The volume of such work depends on how carefully the shop was built in the first place. The more scenarios were thought through during e-commerce website development, the less has to be patched later. But nobody gets this line down to zero, and it has to be in the budget.

• Content edits. Change a description, swap a banner, add a new catalog section.
• Seasonal campaigns. Before the holidays, a shop needs discounts, countdown timers and special collections.
• New payment or delivery options. The market changes and customers ask about what you do not have.
• Small breakages. A form stopped sending mail, a filter shows the wrong products, an image will not load on mobile.
• Partner requirements. A marketplace changed its feed format, a bank updated its requirements for the payment page.

How many hours this really takes

Owners are usually surprised not by the amount but by the number of small things. Here is what an ordinary month looks like for a mid-sized shop.

• Two or three content edits. A new banner, an updated section description, a change to the delivery page.
• One or two small technical jobs. Update a module, fix how something displays on a phone, check why an email did not go out.
• One task from a partner. A changed feed format or new requirements from a payment provider.
• Post-update checks. A quick pass through the key scenarios to confirm nothing has broken.

That comes to between three and eight hours. It is more in peak season and less in quiet months, and over a year it adds up to several dozen hours. This is exactly why the arithmetic depends on your own volume. At that level paying per task usually comes out cheaper, while a retainer starts to pay off closer to the twenty hours of the smallest plan, where an hour of work costs less and unused hours carry over to the next month before they expire.

Work can be paid for as it happens, $25/hr, or taken as a project support retainer where the hours are set in advance, from $400/mo.

Email that stops arriving

A line that appears in no quote at all, and usually the last one anybody notices.

A shop sends mail constantly: order confirmations, status changes, password resets, replies to questions from the contact form. If all of that goes out through an ordinary mailbox on the hosting account, some of it lands in spam, and that is hard to spot, because as far as the shop is concerned every message went out successfully.

It normally comes to light by accident. A customer calls to say the confirmation never arrived. The owner checks and sees that the message was sent. Only after the third such call does it become clear that it is not one message going to spam but a large share of them.

The fix that works has two steps. First, set up SPF and DKIM records for the shop’s domain, because without them Gmail and other providers may send mail to spam or reject it outright, wherever it comes from. If messages still land in spam after that, or the shop starts sending far more mail, sending moves to a separate transactional email service. It has a free tier that a small shop stays within, and paid plans once the volume grows. Both steps are done once and close off most of this category of trouble, which otherwise gets blamed on anything but the mail.

Checking your own situation takes ten minutes. Place three test orders using mailboxes at different providers and see where the messages land.

Advertising, analytics and other services

A shop without traffic does not sell, so the advertising budget is spent every month too, but it belongs in a separate column from running costs.

We run Google Ads campaigns as part of our Google Ads management service.

Analytics is a special case here. You pay for the setup once, and without it every other cost turns into guesswork. Not knowing where orders came from makes it impossible to tell which budget line works and which does not.

What happens when people skimp here

Cutting corners on running costs produces a predictable set of consequences, and each one costs more than the amount saved.

• The shop goes down at the peak of the season. The plan cannot take the influx exactly when traffic is most expensive.
• Updates pile up. After a year there are so many that a single update becomes a project in itself, with a risk of breaking a working shop.
• There are no backups, or they are corrupted. Recovery after a failure takes days instead of hours.
• Small glitches linger for months. Each quietly takes away a share of orders, and it is noticed only in the quarterly figures.
• Nobody has the full picture. One-off contractors work out somebody else’s setup from scratch each time, and hours are spent learning rather than doing.

What is worth watching in the first weeks, while these problems are still cheap to fix, is described in our article on the first 90 days of a website after launch. Speed matters here too, because a slow catalog quietly costs orders every day, and the reasons for that are covered in our article on why a website loads slowly.

Costs that only appear as you grow

For the first year a shop lives on one set of costs, and from the second year lines start appearing that were not there before.

• A faster server. The catalog has grown and the filter got heavier.
• Database optimization. Years of orders and logs slow the admin panel down.
• A second language or region. It appears once the market widens.
• Marketplace integrations. Every new marketplace means a separate feed.
• Inventory management. Needed once spreadsheets stop coping.
• Someone to process orders. There are more orders than the owner can handle.

None of these lines can be predicted exactly at the start, but the fact that they will appear can be budgeted for. When a shop doubles in size, its costs rarely double with it. They usually grow more slowly, but in jumps.

The hardest case is when all six lines arrive at once because growth came suddenly. Then the money for them comes out of working capital at the worst possible moment.

How to work out your own monthly figure

The calculation is done once, in a few steps, and then simply refined.

• List every subscription. Hosting, domain, modules, theme, delivery and mailing services, with renewal dates.
• Add the commissions. The payment provider takes a percentage of every order, and that grows with turnover.
• Estimate the hours for fixes. Look at how many tasks came up in the last three months and take the average.
• Set aside a reserve for incidents. One failure a year is a realistic assumption, not pessimism.
• Count advertising separately. That is a sales expense, so judge it by its return.

Divide the resulting figure by the number of orders per month and you get the running cost per order. That number is more useful than the monthly total. Set it against the margin an order brings in, and you will see whether the shop covers these costs at its current sales volume.

It is then worth comparing it with the commission of the marketplace you also sell on. It often turns out that your own shop at the same turnover costs less, but the difference only becomes visible once running costs are counted with maintenance and small fixes included.

One more check takes five minutes. Look at how many of your subscriptions renew automatically from a card you have forgotten about. That is the most common source of surplus lines in a budget, and it is usually discovered by accident.

Conclusions

The running costs of a shop fall into three groups: hosting, module subscriptions and regular maintenance. Module subscriptions can be counted precisely, and hosting is predictable a year ahead if catalog growth is built in. Maintenance varies with how many tasks come up. Advertising sits apart, because it is a cost of sales and should be judged on return.

The most expensive part is the surprise. An owner who worked out the running cost before launch makes calm decisions. An owner who discovers these lines after the fact starts economizing in the worst possible place, which is updates and backups.

If you already have a shop and are not sure you are paying for the right things, send us its address and the list of services you receive invoices for. We will look at what your catalog genuinely needs, what duplicates something you already have and what is not used at all. We will separately flag the subscriptions you can cancel without consequences. If the shop is still at the planning stage, describe your product range and the accounting system you use, and we will price the running costs alongside the build.