Ecommerce development that survives launch day

Ecommerce development is the work of turning a catalogue into a shop that takes money reliably. The storefront is the visible part and usually the smallest: behind it sit the product model with its variants and stock, a checkout that has to handle tax, shipping rules and failed payments, integrations with whatever holds your inventory and orders, and the operational side that keeps the site fast and the data correct once real orders arrive. Most projects that go wrong go wrong in those places, not in the design. A store is a transactional system that happens to have a nice front page, and budgeting for it as a website is the single most common planning mistake.

A small store on a hosted platform with a standard theme and a few dozen products can be open in two to four weeks. A custom build, or one with real integrations to an ERP, a warehouse or a PIM, is usually two to five months, and the long pole is rarely the front end. It is product data cleanup, tax and shipping rules for each country you sell into, payment provider onboarding, and the migration of existing customers and orders if you already trade. Teams that plan for the theme and not for the data are the ones whose launch date moves twice.

Start with the lightest thing that fits your catalogue and your rules. A hosted platform is the right answer far more often than developers like to admit: it covers payments, PCI scope, hosting and updates, and it lets you find out what your business actually needs before you build it. Move to open source or a custom build when your pricing, variant or B2B rules do not fit the platform's model, when per-order fees start to matter at your volume, or when the store is part of a larger system you already own. Whatever you pick, keep your product data, content and URL structure portable, so switching later is a migration and not a rewrite.

There are two costs and teams routinely plan for the wrong one. Build cost: a hosted store with a customised theme typically lands between $3,000 and $15,000; a store with real integrations, custom checkout logic or B2B pricing is more often $20,000 to $80,000; a headless or fully custom build starts higher. Run cost: platform fees, payment processing, apps and hosting add up quietly, and the app bill in particular tends to double in year two. Then there is maintenance — platform updates, browser changes, tax rule changes. Budget roughly 15–25% of build cost per year to keep a store healthy.

Almost always the checkout or the product page, and almost always something measurable rather than aesthetic. In practice: unexpected shipping cost revealed at the last step is the largest single cause of abandonment; a forced account registration is the second; slow product pages on mid-range phones are the third. Then come missing information a buyer needs before committing — delivery date, return terms, sizing, total price including tax — and payment methods your market expects but you do not offer. Instrument the funnel step by step before you change the design. A store that loses two thirds of its carts at the shipping step does not have a design problem.

Use a hosted platform when your catalogue is standard, your rules fit the model and your volume is modest — it is genuinely faster to a working shop and you will learn what your business really needs. Build custom when pricing or variant logic does not fit, when the store must sit inside systems you already own, when per-order fees become a real line at your volume, or when the commerce experience is part of the product you sell. The common path is sensible: prove the business on a platform, then rebuild the parts that earned it.