What an e-commerce build costs, and the ongoing fees to expect

A store owner gets three quotes, picks the number in the middle, signs off, and three months later is paying for a payment gateway integration nobody mentioned, a theme licence that expired, and hours of "support" billed at a rate never discussed upfront. This is the pattern when a build is chosen on the total figure alone rather than on what that figure includes. The gap between a quote that looks affordable and one that quietly covers everything is rarely about who's more honest — it's about what each developer assumed you already knew to ask for.

What the build quote is actually pricing

An e-commerce build isn't one job, it's several stacked together: the platform setup, the design or theme customisation, product catalogue loading, payment gateway integration, delivery and courier configuration, tax and invoicing setup, and testing across devices. A quote that covers all of this will naturally sit higher than one that covers only the visible parts — design and a basic catalogue — because the invisible parts take real hours too. Neither number is wrong; they're pricing different jobs. The question worth asking isn't "why is this one cheaper" but "which of these seven things is in the price, and which becomes a separate invoice later."

Catalogue size changes cost more than most people expect. Loading twenty products with simple variants is a different task from loading two thousand with sizes, colours and stock levels that need to sync with a warehouse system. Custom functionality — a subscription model, a quote-request flow, integration with existing accounting software — adds development time that a template-based build never touches. And testing is easy to skip on a rushed timeline: checking that checkout works on a low-end phone, that a failed payment doesn't lose the order, that stock doesn't oversell when two people buy the last item at once. A developer who quotes for testing time isn't padding the bill; they're pricing the difference between a store that works on launch day and one that breaks on it.

What separates a fair lower quote from a problem isn't the number — it's whether the scope is written down. A quote that lists exactly what's included, what's excluded, and what counts as a change request gives you something to compare and hold them to. A verbal estimate with no scope document is a risk at any price point, budget or premium, because there's nothing to point to when the invoice grows.

The costs that start after handover

A build price is a single payment. Running the store is a subscription to several things at once, and this is where quotes diverge most sharply from what actually shows up in your bank account. There's the platform fee itself if you're on a hosted system, hosting and a security certificate if you're not, the payment gateway's transaction percentage on every sale, an SSL and domain renewal, and usually a small monthly cost for apps or plugins handling things like reviews, abandoned-cart emails or stock alerts. None of these are optional extras a developer invents — they're the actual cost of keeping a store live, secure and able to take payments.

Where quotes genuinely differ is support after launch. Some developers include a fixed window of free fixes and small changes after handover; others charge from the first support ticket. Ask directly what happens when something breaks in month two, and what an hourly support rate looks like if you need help beyond that window. Ask too whether they're using licensed themes and plugins under your name or theirs — a plugin registered to the developer's account rather than yours can leave you locked out or paying twice if you ever switch providers.

Comparing these ongoing costs side by side, not just the once-off build fee, is the only way to see the real total. Strove lists developers who set out their scope and their after-launch costs upfront, which makes that comparison something you can actually do before you commit rather than discover afterwards.