What actually makes a commerce build slow
Ask three agencies how long a headless storefront takes and you'll get three months, four months, and "depends". None of them are lying. They're describing a process where most of the calendar isn't spent building.
We quote four weeks. Here's the honest arithmetic behind that, including the parts that aren't ours.
Why four and not twelve
The number isn't a productivity claim. It's an inventory claim.
A traditional build spends its first several weeks assembling a platform: the commerce engine, the admin, the data model, auth, the deploy pipeline. Everyone builds roughly the same thing, and everyone bills for it.
We don't start there. The engine, the admin, and the AI layer already exist and run — it's the platform we've been building on for a while. So the four weeks goes on the part that's actually yours: your storefront, your catalog, your integrations, your brand.
That's the whole trick, and it's not a very clever one. It just means the question "how long does it take" has a different answer depending on how much of the thing already exists.
What actually eats the calendar
Now the uncomfortable part. In our experience the projects that miss don't miss on engineering. They miss on these, in roughly this order:
Design revision loops. The single biggest one. Two concepts and one round of feedback is a week. Two concepts, three rounds, and a stakeholder who joins in week three is a month — and the engineering hasn't started, because there's nothing settled to build.
Content that isn't ready. Product copy, photography, category structure, the About page nobody's written. Every build we've seen stall has stalled here at least once. It feels like a small thing until you're waiting on 400 product descriptions to start the thing that needs 400 product descriptions.
Decisions with no owner. "We need to check with marketing" is a two-day delay if marketing has an opinion and a three-week delay if nobody's sure whose call it is. This one is invisible in a plan and lethal in a calendar.
Integration surprises. Your ERP has an API, technically. Someone has the credentials, probably. It returns prices in a shape nobody documented, and the person who built it left. Real, common, and it doesn't show up until week two.
Scope that arrives sideways. Never as "let's add a feature". Always as "can it also just…". Each one is small. Six of them is a fortnight.
None of that is a client failing. It's what happens when a project touches a business that has other things going on. But it's why "four weeks" has to be a two-sided number.
So the four weeks has conditions
We say them up front, because a date we miss costs everyone more than the date we quote:
- Scope signed before kickoff. Written down, agreed, not "roughly agreed".
- Content and catalog in hand at kickoff. Not promised for week two.
- Design decided in week one. Two concepts, one revision round, one decision-maker.
- Change requests get their own scope and their own timeline. Not a "quick add".
That last one sounds rigid and it's the kindest term in the list. The alternative is a project that quietly absorbs six small requests and delivers three weeks late, and then everyone argues about why.
What four weeks does and doesn't cover
Four weeks gets your storefront live with your catalog, your branding, and the AI layer working. It doesn't include everything a business needs to actually trade:
- Payments, shipping zones, tax setup, domain and DNS — days, not weeks, but they're days
- Migrating historical orders and customers — depends entirely on where they're coming from
- Marketplaces and complex migrations — longer, and we'll say so at the workshop
Anyone quoting you a single number for all of that is quoting you a feeling.
How to read any timeline you're given
Ask what they're building versus assembling. If the answer is that they build the platform each time, most of your quote is a thing that already exists elsewhere and you're paying to have it made again.
Then ask what's on your side of the line. A vendor who won't tell you what they need from you and when hasn't planned the project. They've planned their part of it, which is the easy half.