How long does a Shopify store rebuild take?

Timeline quotes for the same store range from two weeks to six months, which tells you the quote reflects the vendor’s process more than the work. Here are the real bands and what moves a project inside them.

The honest bands

A landing page: about a week. One template, one purpose, tracking included. If a vendor quotes a month for a landing page, you are paying for their queue, not the work.

A facelift: one to two weeks. Custom cards, homepage merchandising, reviews surfaced, speed work. It ships fast because nothing replatforms: every change stages on a copy of the live theme, and the store keeps selling through the whole project.

A full custom rebuild: two to four weeks. Theme, catalog architecture, page templates, imagery, tracking. That is the window on my published Storefront Build card, and four weeks is the honest ceiling for a big catalog with imagery gaps.

A large catalog or a platform migration: longer, and priced differently. Thousands of SKUs with real specification data, a redirect map protecting existing rankings, or part-number and fitment search. That work runs $15,000 to $30,000 and does not compress into a month. Any vendor who says it does has not done one.

The agency version: a quarter or more. The quotes founders bring me attach twelve-plus weeks to the same scope. The added time is coordination: a project manager, a designer, a developer, and QA passing the work between them, with meetings at each handoff.

The worked example: 150 SKUs, under a month, one person

A premium home furnishings brand on Shopify. Statement furniture priced $999 to $7,500. Sofas, dining tables, vanities, media cabinets, mirrors, lighting. Roughly 150 products, and photography for almost none of them.

The conventional staffing for that launch is four people: a brand photographer for hero imagery, a product photographer for 150-plus SKUs against white, a Shopify designer for the theme, and a project manager keeping the three in sync. Twelve to sixteen weeks. Mid five figures.

Here is where the calendar goes in the four-person version. Photography alone is a scheduling problem before it is a production problem: product has to ship to a studio, get shot, come back, and the edited files have to land before the designer can build the collection pages that display them. The designer waits on the photographer. The developer waits on the designer. The project manager waits on everyone and reports on the waiting. Very little of a twelve-week timeline is work. Most of it is queue.

The version that shipped ran three workstreams in parallel because one person held all three. The full custom theme, built for the positioning rather than forked from a template. Shop-by-room architecture (Living Room, Bedroom, Dining Room, Bathroom) plus category navigation (Seating, Tables, Storage, Vanities, Lighting, Mirrors). And 150-plus product images produced through an in-house render pipeline, with tight control on lighting, materials, perspective, and shadow physics, plus a per-category style lock so a console table tile does not render under a different lighting setup than the side table next to it in the grid.

Kickoff to public launch: under a month. Outside hands: zero. Product shoots commissioned: zero. The case study documents it, including the source-to-render comparisons.

What the timeline should include

A build is not done when it looks done. The closing stretch of a real timeline holds the work that invisible-until-launch projects skip: conversion tracking wired into the new templates and validated end to end, redirects mapped, page speed measured on a phone over cellular, and a staged launch where the old store keeps selling until the moment of cutover.

A quote that beats these windows by skipping those is quoting a different, worse project. The tracking rebuild alone is a $2,500 engagement when bought on its own, which is a useful way to price the omission.

What stretches a timeline

Four things, in order of how often I see them.

Catalog size. 700 products is a different project than 70. Collection architecture, filtering, and variant handling all scale with the count.

Imagery gaps. If half the SKUs have one bare supplier photo, producing catalog imagery becomes its own workstream. It is why I run an in-house render pipeline, and why the furniture build above stayed inside a month instead of waiting on studio bookings.

Approval lag. The single biggest variable nobody quotes. A founder who reviews in a day keeps a build on pace. A committee that reviews in two weeks can double the calendar by itself, and no vendor can absorb that from their side.

App surgery. Subscriptions, bundles, B2B pricing, ERP feeds. Each integration adds build and testing time, and testing is the half that gets underestimated.

Why my timelines read short

Not heroics. The build runs through a system: a written playbook for every repeatable step, templates and checks accumulated across every build before yours, and one senior operator instead of four people passing work between them.

Fewer handoffs is most of the answer. The same person doing the theme also wires the tracking, so the two workstreams never wait on each other. The rest is scope discipline: a build with a defined end date has a defined scope, and I would rather say no to a feature in week one than discover it in week five.

The question to ask any vendor

Ask what happens in week one.

A builder with a working system starts building in week one. A process-heavy shop spends weeks one through three on discovery decks. Both can produce a good store. Only one of them does it this quarter.

Then ask what happens in the last week, because that is where tracking, redirects, and the speed check either live or do not. Timelines and pricing for my builds are published at /storefronts, and the risk checklist for the cutover itself is at redesign without losing sales.