Quick answer
A configured store on a bought theme can be live in days to two weeks. A customised theme is typically three to six weeks. A theme built from scratch is six to twelve. Add two to four weeks for a real migration.
What makes builds run long is almost never development: late product content, undecided collection structure, requirements arriving in week five, integration access, and review cycles with no single decision-maker. Get one product page complete with real content first; it settles more arguments than a month of mockups.
Every honest answer to this question is a range, and the range is set by things that are not development. Here is what each scope actually takes, and what reliably makes it take longer.
01 · Ranges
Four scopes, four honest ranges.
A configured store on a bought theme. Products, collections, a homepage, payments and shipping. Days to two weeks, and the variable is your product data, not the build.
A customised theme. A bought base with your brand applied properly and a handful of purpose-made sections. Typically three to six weeks. Most of the client stores on this site sit here.
A theme built from scratch. No Theme Store base, every template designed. Six to twelve weeks, and that assumes the design is decided rather than being explored during the build.
A migration. Add two to four weeks to any of the above for a real migration: data mapping, redirect mapping, testing what the old platform did that nobody documented.
02 · The real delays
It is almost never the code.
Across the builds we have shipped, the things that pushed dates were, in order:
- Product content. Photography, descriptions and specifications arriving late or inconsistently.
- Undecided structure. Nobody agreed how collections nest, so the navigation cannot be built.
- Late requirements. Subscriptions or wholesale appearing in week five, needing a different product architecture.
- Integrations. ERP, 3PL or POS access taking two weeks to arrange, then behaving differently than described.
- Review cycles. Feedback from four people who disagree, delivered one at a time.
Notice that a developer can only fix the last two, and only partly.
03 · Critical path
Content decides the date.
A store cannot go live with placeholder products. It can go live with a plainer homepage. That asymmetry tells you where to spend the first week: get one product page complete and correct, with real images, real copy, real options and real shipping information, before anything else is designed.
One finished product page settles more arguments than a month of mockups, because it forces every unresolved question into the open: what the variants are called, what the size guide says, what happens when it is out of stock, what the delivery promise actually is.
04 · Sequencing
What can genuinely run at the same time.
Design and content production run in parallel, and should. So do integration access requests, which is why they should be started in week one rather than when the code is ready for them.
What cannot run in parallel: navigation before collection structure is decided, product templates before the product data model is settled, and launch QA before the content is real. Trying to parallelise those produces work that gets redone.
05 · Compression
Shorten it without lying about it.
Launch narrower rather than later. A store trading with three collections and one excellent product template beats a store six weeks from a complete catalogue. Shopify makes adding the rest afterwards cheap; that is the whole point of the platform.
Name one decision-maker. Most schedule slip is consensus cost, not build cost.
Freeze scope at a defined point and put anything later into a written after-launch list. This is not bureaucracy; it is what stops week five requirements from resetting week two decisions.
Quick check
Before you commit.
- The scope is named: configured, customised, from scratch, or migration.
- One product page is complete with real content before design expands.
- Collection structure is decided before navigation is built.
- Integration access was requested in week one.
- One person makes the final call on feedback.
- There is a written after-launch list, and things are allowed onto it.
The date is set by decisions, not by code.
Ask what has to be true to launch, then find which of those things nobody owns yet. That is your real timeline, and it is usually fixable in a meeting rather than in a sprint.
Questions
Questions people ask.
How fast can a Shopify store realistically launch?
Days, if the product data and images are ready and you are configuring a bought theme rather than customising it. The build is rarely the constraint at that scope; product content is.
Why do Shopify builds take longer than quoted?
Because the quote covers development and the delays are elsewhere: photography and descriptions arriving late, collection structure still undecided, subscriptions or wholesale appearing mid-build, integration access taking weeks, and feedback from several people who disagree.
Should I wait until everything is ready to launch?
No. Launching narrower is almost always better than launching later: three collections and one excellent product template beats a complete catalogue six weeks from now. Adding the rest afterwards is cheap on Shopify.