What it really costs to build an online store

A quote answers three separate questions, and people usually ask only the first. What does the software cost to run, who assembles it, and how much bespoke work does your business genuinely need. A hosted platform answers question one with a subscription and question two with your own evenings. A freelancer working from a template answers question two with a fee and leaves question three near zero. A custom build is mostly question three — every hour is somebody deciding how your catalogue, pricing rules or fulfilment should behave rather than accepting a default. So when you compare two quotes that differ by a factor of ten, you are almost never comparing the same store. You are comparing different answers to which of those three questions you are paying to have solved, and the cheaper quote is often the one that quietly leaves the third to you.

For a first store with fewer than a hundred products and no unusual rules, the cheapest legitimate route is a hosted platform and your own time. You pay a monthly subscription, pick a theme, and accept its decisions about layout, navigation and checkout. What you commonly see is roughly $30 to $80 a month for the platform, plus a paid theme somewhere in the $150 to $400 range — and the real cost is the two to six weeks of evenings. This suits somebody testing whether a product sells at all. The trade-offs deserve naming: an extra transaction fee if you use an outside gateway, apps that each carry their own monthly charge, and a ceiling on how much you can change once the catalogue outgrows what the theme assumed. Where a hosted platform stops and a custom storefront starts sets out that boundary honestly.

The middle route is WordPress with WooCommerce, a commercial theme, and a contractor to assemble it. Ranges you commonly see run from around $1,500 for a small catalogue on a stock theme to $10,000 and up once you need custom templates, product imports and integrations. It buys ownership: your data, your hosting, nobody taking a cut of each order. It also buys a maintenance obligation that rarely appears in the quote. The usual failure is not the theme but what gets stacked on it — a page builder, a slider, a filter plugin, a review plugin, then three optimization plugins to counteract the first five, until the storefront is slow in a way no single plugin caused. Plugin bloat explains that mechanism. Hire on the assumption you will need this person again within a year, because you will.

• Who owns the code, the licences and the hosting account
• What the theme and paid plugins cost to renew each year
• Whether product import and content entry are in scope
• What happens when something breaks three months after launch

A custom build means the customer-facing storefront is written for your store rather than configured from a theme. Figures here usually start in the low five figures and climb, because you are paying for judgement — how a two-thousand-product catalogue should filter, how a wholesale tier should price, how a category page should render fast on a mid-range phone. It is rarely the right first purchase. It becomes justified when there is measurable traffic being lost to something a template cannot fix, or when the operating model genuinely does not fit the defaults. Our own engagements start at $1,999, which covers focused work rather than a whole storefront; the packages and what each includes are public so you can place yourself in the range before contacting anybody, and how the work runs covers sequence, testing and handover.

Almost every over-budget first store is over budget on things that were never development. A domain and hosting are small and permanent. Paid plugins and themes are usually annual licences rather than one-time purchases, and they stop receiving security updates when the licence lapses. Payment processing takes a percentage of every order forever — commonly around 2.9% plus a fixed fee per transaction for US card payments, and more for international cards. Then there is content: photography and written descriptions for every item, which at a hundred products is a project of its own. Shipping and tax configuration takes real hours. Legal pages — returns, privacy, terms — are not optional. And the largest missing line is usually the launch marketing budget, without which the store has no visitors, no orders and no data to improve from.

• Domain, hosting and SSL: small, recurring, permanent
• Theme and plugin licences: annual renewals, not one-time
• Payment processing: a percentage of every order, forever
• Photography, copy, legal pages and launch spend

Treat the build as the deposit and the running cost as the rent. A live store carries obligations whether or not anybody touches it: hosting, licence renewals, WordPress and plugin updates, backups, security patches, and somebody available when a payment gateway changes its API. Skipping these does not save money, it defers the money into an outage during your busiest month. Budget a monthly figure from day one instead of treating maintenance as an emergency purchase. Our Care Plan starts at $150 a month and exists so that this line is predictable rather than alarming; what ongoing maintenance actually covers sets out the scope. Whichever route you pick, the honest planning question is not what the build costs. It is what twenty-four months of the build plus its running costs adds up to, and the calculators let you set your own sessions and margin against that total.

• Hosting, domain and certificate renewals
• Theme, plugin and app licence renewals
• Updates, backups, security patches and uptime monitoring
• Payment percentages and any platform transaction fee

A cheap build is rarely cheap because somebody worked for less. It is cheap because decisions were deferred. Defaults were accepted, plugins were installed instead of behaviour being built, content was left as placeholder, and nothing was measured. Each deferral becomes a bill later, and the later bill is larger because it now includes unpicking the first attempt. Two costs dominate. The first is rework: a storefront assembled from ten overlapping plugins usually cannot be optimized incrementally, so the second engagement is a rebuild rather than a repair. The second is opportunity cost, and it is the bigger of the two — every month a slow or confusing store converts below what its traffic could support, you pay the difference in orders you never see. That gap appears in no quote, which is precisely why nobody budgets for it.

If you have not yet proved that somebody will pay for what you sell, the correct budget is the smallest amount that lets you take money at all. That means a hosted platform, a stock theme, ten products photographed against a plain wall, and the rest of the money spent getting a few hundred strangers to look. A carefully built storefront in front of unvalidated demand is an expensive way to learn something a rough one teaches faster and sooner. There is a second case for waiting. If you already sell through a marketplace or direct messages and it works, your own store is a diversification project rather than a rescue, and it can wait until margin justifies it. Spend on a real build when you have order data telling you what the store must handle — not before.