E-commerce website development: what the whole build actually involves

Stage 1 — model the catalogue before you choose anything

The single most expensive mistake in an e-commerce project is choosing a platform before anyone has written down what a product is. It sounds like a trivial question until you try to answer it for a real business.

A t-shirt has two variant axes: size and colour. A proxy plan has four — type, location, bandwidth and term — and each combination has its own price and its own stock position. A made-to-measure curtain has a price that is a function of two continuous dimensions plus a fabric choice, which is not a variant at all but a formula. These three businesses need three different data models, and the platform that handles the first one gracefully will fight you for months on the third.

So the first deliverable of any build I run is not a design. It is a written model: what a product is, what varies, what each variation does to price and stock, and what the customer must choose before they can add to cart. Every later decision is downstream of that document.

• How many products, and how many valid variants of each?
• Which attributes change the price, and by how much — fixed uplift, percentage, or formula?
• Is stock tracked per variant, per product, or not at all?
• Are there combinations that must never be sellable together?
• What does the customer have to know before they can buy — measurements, compatibility, delivery window?

Stage 2 — platform choice is a cost-of-ownership decision

There are three honest options for a small or mid-sized store, and the right one is decided by the catalogue model, not by preference.

I build custom stores and WooCommerce sites, and I will tell a client to use Shopify when Shopify is the right answer. Selling someone a custom build for a straightforward twenty-product catalogue is how agencies make a margin and lose a reference.

Stage 3 — the front end is the cheap part, and it is not the risky part

Design and front-end build is where clients expect the money to go, and it is usually the least risky stage. It is visible, it is easy to review, and mistakes are cheap to correct because nothing depends on it yet.

The two decisions in this stage that genuinely matter later are both structural. First: what does a category page look like when the customer arrives from a search engine with a very specific intent — because that page, not the home page, is where most sessions start. Second: does the product page carry the information that removes the last objection, or does it require a phone call to complete a purchase?

Stage 4 — payments, tax and shipping are where builds actually fail

Checkout is not one feature. It is a payment integration, a tax rule set, a shipping rule set, and an order lifecycle, and each can fail independently in ways that look identical to the customer.

The pattern I use, and the one I would want any developer to use on your project: payment confirmation drives fulfilment through the provider webhook, never through the browser redirect. A customer who closes the tab after paying is common. In a redirect-driven flow they are charged and receive nothing, and you find out when they email you angrily. In a webhook-driven flow their order completes whether or not the browser survives.

• Test declines, 3D Secure challenges, partial refunds and duplicate submissions — not just the happy path
• Decide the tax position before you build: where you are registered, what you charge, what appears on the invoice
• Shipping rules by weight, zone and value, with an explicit answer for the countries you will not ship to
• Order confirmation email from an authenticated domain with SPF, DKIM and DMARC aligned, or it lands in spam
• An admin view where a non-technical person can find one order in thirty seconds

Stage 5 — pre-launch QA that assumes something is broken

The point of QA is not to confirm the site works. It is to find the case where it does not, before a customer does. I run every build against the same list, and I have never once found nothing.

1. Buy something. With a real card, on a phone, on mobile data rather than office wifi.
2. Buy something that is out of stock, and something with the maximum quantity.
3. Abandon a checkout halfway and come back an hour later.
4. Submit every form with the fields empty, then with 5,000 characters of text.
5. Navigate the entire purchase with a keyboard alone, then with a screen reader.
6. Open every page on a five-year-old Android phone on a throttled connection.
7. Check the order confirmation email arrives, in the inbox, not in spam.

Stage 6 — indexation is part of the build, not a later project

A store that launches unindexed is a shop with the shutters down. The work that has to happen inside the build — not six months later when someone notices there is no traffic — is small and specific.

Crawlable category and product URLs with clean paths. One canonical per product, even when the same product is reachable through three category paths. Product schema with price and availability that match what is on the page. An XML sitemap generated from the catalogue rather than hand-written. A robots.txt that does not accidentally exclude the shop directory. Server-rendered HTML, so a crawler that does not execute JavaScript still sees the product text — which is exactly the failure this very site was rebuilt to fix.

None of that is expensive during a build. All of it is expensive afterwards, because the fixes are structural and the traffic loss compounds while you wait.

What a realistic timeline looks like

One week end to end for a standard catalogue store. That is only achievable because the sequence above is fixed rather than improvised, and because your product content exists on day one — waiting on copy and photography is what actually stretches a build, not the code.

What should worry you in a quote is not a short timeline. It is a quote given before anyone asked what a product is. That question is stage one, it decides everything downstream, and a supplier who skips it is guessing at your catalogue and will discover the problem in your build rather than in their estimate.

Questions people ask about this

How much does an e-commerce website cost?

A standard catalogue store with working checkout starts at $150 when you hire direct. A UK or US agency will quote several thousand for the same scope, and most of that gap is location and overhead rather than output. What moves my number is catalogue complexity, integrations, and how far your catalogue model sits from a normal product grid.

Should I use Shopify instead of a custom build?

If your catalogue is conventional and you want to be trading next week, yes — and a developer who will not tell you that is selling you their preference. A custom build wins when the checkout carries business logic, when the catalogue does not fit a product grid, or when the monthly platform and transaction fees will outrun the build cost.

How long before the store gets traffic from Google?

Indexation happens within days if the technical setup is right. Ranking for competitive commercial terms on a new domain realistically takes three to six months of consistent content and links. Anyone promising page one in thirty days is describing a keyword nobody searches.

Who owns the site when it is finished?

You should. Your hosting account, your domain, your payment provider account, your code. If a supplier resists that, the reason is commercial lock-in, not technical necessity.

Who wrote this

Anas Bin Masud builds e-commerce sites and does technical SEO for businesses in the UK, Canada and Pakistan — fifteen live client sites, six of them stores taking real payments. The examples in these guides come from those builds and from the audit that rebuilt this site, not from a content brief. More about how I work, or read the case studies.