“When can it be live?” is the second question every client asks, and the honest answer has a shape rather than a number. A studio that gives you a date without asking what you can supply and how fast you can decide is not estimating; it is guessing in a confident voice.
So here is the shape, and the two things that bend it.
Roughly how long each shape takes
Measured from a signed proposal to a live site, assuming decisions arrive within days rather than weeks:
- A presence on a good template. Two to four weeks, and most of that is content rather than build.
- A custom small site. Six to ten weeks: a fortnight of deciding and designing before anything is built.
- A site with a job — integrations, lead flows, measurement. Ten to sixteen weeks, and the range widens with every external system.
- A store. Three to six months, dominated by catalogue, payments, tax, shipping rules and migrating what you already have.
- A product. A first usable version in a quarter if the scope is cut properly, and then it never really finishes, because products do not.
Those bands describe work, not calendar. The calendar is longer, and the difference between the two is where every unhappy conversation about deadlines comes from.
Why the build is the shortest part
People picture a schedule as coding time with a little decoration at each end. On a project that goes well it is closer to the reverse: a third of the calendar is spent deciding and designing, a third building, and a third on content, testing, migration and the launch itself.
That is why adding developers rarely rescues a date, and why the phases everyone wants to skip are the ones that set the pace. It is also why a studio that quotes a build number without a discovery phase has quoted the middle third and left you to discover the other two.
The two causes of most slippage
Content. Real text, real photographs, real product data. This is the single most common reason projects run late, and it is nearly universal: the build is finished and the site sits waiting for the About page nobody wants to write. Content takes longer than people expect because it requires deciding what you actually claim about yourself, which is a harder task than approving a layout.
Undecided decisions. Not disagreements — silence. A question goes out on Tuesday, the person who can answer it is travelling, the work parks, and a week is gone that no schedule accounted for. Multiply that across a project with several approvers and the calendar quietly doubles while the actual work stays the same size.
We are not saying this to shift blame. We are saying it because both are fixable in advance, and because a studio that does not warn you about them is either inexperienced or planning to bill you for the wait.
The third cause, smaller but sharper
Systems you do not control. An old warehouse tool, a payment provider in a new market, an ERP whose documentation is a PDF from 2019, a vendor whose support replies in five working days. Every integration is a small project with an unknown edge, and the honest way to schedule one is a range with a named risk rather than a date.
Ask early which integrations are on the list, and ask who at the other company will answer questions. If the answer is “nobody yet”, that item is not scheduled, it is hoped for.
What a real schedule looks like
A useful plan attaches dates to decisions, not only to deliverables. It says: design direction approved by the 14th, all copy delivered by the 21st, product data exported by the 28th — and it states plainly what moves if one of those slips.
That last part is what makes it a schedule rather than a wish. When a client hands over content two weeks late and still expects the original launch date, somebody is about to absorb two weeks, and it will either be quality or somebody's weekend. Writing the dependency down in advance turns that into a conversation instead of a surprise.
It is also worth asking what a studio's queue looks like. “We can start next week” and “we can start work on your project next week” are different sentences, and the gap between them is where a fortnight hides.
Agree what "live" means
Half the arguments about deadlines are really arguments about definitions. Live can mean the pages are visible, or it can mean analytics is recording, redirects from the old URLs work, the forms have been tested from outside the office, backups run, someone has been shown how to publish, and the accounts are in your name.
The second list is the one that matters, and it takes days rather than hours. Put it in the plan as its own step with its own dates, or it will happen in a rush on the evening of launch, which is how sites go live without analytics and nobody notices for a month.
How to compress a date honestly
There are four levers, and only four.
- Cut scope. Launch three pages instead of twelve and add the rest afterwards. Cheapest and most effective, and almost nobody chooses it first.
- Decide faster. Name one person who can approve without a meeting. This regularly buys more time than any amount of extra hands.
- Prepare content in parallel. Start writing and photographing while design is happening, not after it is approved.
- Launch in phases. The part that earns money goes first; the rest follows on a normal schedule.
What does not work is adding people. A project is late because of unanswered questions and missing content, and neither is solved by another developer arriving to read the codebase. Overtime buys days, not weeks, and it is paid back later in defects.
What launching in phases actually looks like
Phased launch sounds like a compromise and behaves like an advantage. A store goes live with its best-selling category, real payments and real customers while the remaining catalogue is still being photographed. A service site launches with the three pages that answer the questions people ask before enquiring, and the library of case material follows in month two.
Two things happen. You start earning earlier, and you get real behaviour to design the rest against instead of opinions in a meeting. The cost is discipline: somebody has to decide what belongs in the first slice and hold that line while everyone lobbies for their page.
Our own record
We have delivered on the date and we have missed it. When we have missed, the cause has almost always been on the list above, which is why the list exists — and once, memorably, because we underestimated migrating data out of a system whose export was a lie. We now schedule migrations as their own phase with their own risk line.
The most useful question you can ask before signing anything: what do you need from us, and by when, for this date to hold? A studio that answers precisely has run real projects. A studio that says “just the go-ahead” has told you the estimate is decoration. That question belongs next to the other eight in how to read a proposal, and the answer usually shapes the budget as much as the scope itself.