How Long Does It Take to Build an Ecommerce Website?
The build is rarely the long part. Product data, photography, written descriptions and decisions nobody has made yet take considerably longer. Almost all of those sit on the client's side of the table.
The Range, And Why It Is A Range
In our own work the span runs from a few weeks to several months. A small shop with a clean catalogue on a well configured theme is measured in weeks. A larger build with integrations, thousands of products and bespoke design is measured in months, occasionally quite a few of them.
That is a wide range and narrowing it is easy, because the things that move a project to each end are knowable at the start rather than discovered halfway through.
Towards the short end. A modest catalogue. Product data already in a clean, structured, consistent state. Photography that exists and is usable. A configured theme rather than a bespoke design. One decision maker who is available. No integrations. No existing shop to replace.
Towards the long end. A large catalogue with variants. Product information scattered across suppliers, spreadsheets and an old system. Photography that has to be produced. Bespoke design. Several people whose approval is needed. Integrations with stock or accounting. And an existing shop that is trading and cannot be switched off.
Notice how many of those sit with the client rather than with the agency. That is the point of this page. It is not an excuse in advance, either. It is the single most useful thing a buyer can know before starting, because most of those items can be prepared in the weeks before a project begins.
The Phases
Every project runs through the same six stages. The share of time each takes surprises people, because it is not the shape they expect.
Discovery and structure. Working out what the shop has to do, how the catalogue divides and what the category tree will be. A small share of the calendar and a disproportionate share of the outcome, since almost everything afterwards depends on it.
Design. How it looks and how the key page types behave. Moderate. It runs faster when the structure above it is already settled.
Build. Making it work. Frequently the shortest phase of the six, which is the part buyers find hardest to believe, since the build is the thing they think they are purchasing.
Content and data loading. Usually the largest phase by a distance and almost always underestimated. Product information, images, descriptions and policy pages all have to exist and then have to go in.
Testing. Checking it works on real devices, including placing a genuine order and a genuine refund. Always the phase that gets compressed when something has slipped, which is precisely when it should not be.
Launch. Short in itself and it needs planning, particularly where an existing shop is being replaced.
What Actually Takes The Time
Four things, none of which is the build.
Product data in a usable state. The largest single item on most projects. It has to be complete, consistent and structured before anything can be loaded. Almost no business has it in that condition when they start.
Photography. Consistent images across the whole catalogue, which cannot be produced in an afternoon and cannot sensibly be left until the build is finished.
Written descriptions. Somebody has to write them. If nobody has been assigned, nobody is writing them. This is discovered late.
Decisions nobody has made yet. Delivery rules by weight and region. Returns terms. What the categories are actually called. What happens to a discontinued product. These feel like details until a build stops because nobody can answer one.
Which produces a result that sounds wrong and is reliably true. A project with two hundred products can take longer than one with two thousand. Two thousand products in a clean structured export with consistent attributes and matched images will load in an afternoon. Two hundred spread across supplier PDFs, a legacy system with inconsistent naming and photographs named by camera have to be assembled by hand, one at a time. Volume is cheap. Mess is expensive. Only one of the two is visible when a project is quoted.
What The Client Controls
A large share of a project's timeline belongs to the client. Saying so is not a defence prepared in advance. It is the information that lets a buyer protect their own launch date.
Approvals. How quickly work comes back with a decision on it. Two days or two weeks, repeated across a project, is the difference between two timelines.
Content. Descriptions, policy wording and anything else that has to be written by somebody who knows the business.
Product information. Covered above. It belongs here too, since it is the client's data.
Access. Domain, hosting, payment accounts, the existing platform and any system that has to connect. Frequently held by somebody who left, sometimes by a previous supplier who is slow to respond.
Decisions. Named above and worth repeating, because they need one person who can settle them.
There is a compounding effect worth knowing about, since it explains why delays cost more than they appear to. A project that stops does not simply resume where it left off. People get assigned elsewhere, context has to be rebuilt and a slot in a schedule has to be found again. A fortnight of waiting on an approval can cost a month of calendar, which is why the useful question during a build is not how it is going. It is what you are waiting on from us.
Migrating An Existing Shop
Replacing a trading shop takes longer than building a new one. Buyers consistently expect the opposite, on the grounds that the content already exists.
Data mapping. The old structure has to be translated into the new one. Categories that do not correspond, attributes stored differently, products that exist twice. This is detailed work and it cannot be rushed without losing something.
Redirects. Every address on the old shop needs a destination on the new one. Products, categories, filtered pages and anything ever linked to from outside. Getting this wrong is the commonest way a business loses visibility during a change.
Preserving what already works. An established shop has search visibility that took years to build. The objective is to arrive on the other side with it intact. That constrains decisions a new build would take freely.
Carrying over what customers expect. Orders, accounts, stored addresses and reviews. Reviews in particular are frequently lost, because nobody asks about them until it is too late.
You cannot turn the shop off. The old one keeps trading while the new one is prepared, which means running two systems and keeping stock and prices aligned across both.
Migrations are their own discipline and they belong in our site migrations guides rather than being compressed into a block here.
What A Rushed Build Costs Later
Time pressure does not distribute itself evenly across a project. It lands hardest on exactly the decisions that are most expensive to reverse. The reason is structural rather than a matter of anybody being careless.
Structural decisions come first, because everything else depends on them. Category structure, address patterns, how filters behave and what page types will exist are all settled in the opening days, when the deadline feels distant and the temptation is to move quickly so the visible work can start.
Those are the decisions that cannot be adjusted afterwards. A design that turns out to be wrong can be changed on a live shop in an afternoon. A category structure that turns out to be wrong means new addresses, redirects from every old one and a period of disruption while it settles. One is a revision. The other is a rebuild.
So the asymmetry is unhelpful. The parts taken quickly under pressure are permanent, while the parts everybody spends the pressure protecting are the adjustable ones.
The practical consequence for a buyer is that a compressed timeline should compress the design and build phases rather than discovery. An agency proposing to save a fortnight by shortening the structure work is proposing to save it out of the only phase where the savings are permanent. Why those decisions matter so much is set out in how web design affects ecommerce SEO.
What Delays Almost Every Project
Specific rather than general, because a generic list of risks helps nobody. These are the things that genuinely stop projects.
Product data arriving in pieces. A partial file, then corrections, then a second file that contradicts the first.
Photography not booked until the build is finished. By which point it is the only thing standing between the shop and launch. Photographers have diaries.
One person able to approve, then that person on holiday. Entirely predictable and it happens constantly.
Payment account applications. These involve checks that take as long as they take. Starting them late is a self inflicted delay that nobody sees coming.
Delivery rules nobody will decide. Weight bands, regions, thresholds and what happens to bulky items. The build cannot proceed past a certain point without answers.
Access to the old system. Held by a previous supplier who is in no hurry, sometimes by an ex employee.
Additions arriving late. A marketplace connection remembered in week six, which was never in the scope and now sits in the middle of the schedule.
Nearly all of those can be removed before a project starts, which is what our guide to what to expect during an ecommerce web design project is for.
We tell you what
sits on your side.
Before a project starts we set out exactly what we need from you and when, because a fortnight of waiting on an approval can cost a month of calendar. Structure and search architecture are decided first, since those are the parts a rushed timeline makes permanent.
What a build covers:
Ongoing management afterwards sits inside our fixed monthly fee. Build work is quoted per project.
Twenty guides.
One subject.
This page covers timescales. The rest of the series covers what a build costs, what to prepare before starting, which platform suits which business and why the search ceiling is set during the build.
