Answer in brief
A developer counts their own work and not your approvals, text and access credentials — which is about half the project. What a timeline is actually made of, and what can genuinely be sped up.
Why the quoted timeline is always shorter than reality
When a developer quotes a timeline, they honestly count their own work. They do not count your approvals, the wait for text, access to the payment system, or the fortnight that goes on let us look at that once more.
This is not deceit. They will genuinely do their part in the time quoted, if everything else arrives when it should. The trouble is that everything else is about half the project, and it is yours.
Hence a practical rule that is rarely stated out loud: the development timeline and the launch timeline are different numbers, and the second is roughly half again as long as the first.
Below is what each is made of, what runs in parallel and what does not, and the signs visible in week two that the schedule is going to move.
What the timeline is made of
Six stages, and development is not the longest of them.
Brief and estimate: a few days to a fortnight. Entirely down to you — how ready you are to state the job.
Design: from a week for a standard layout to a month for a bespoke one with several states for every block.
Development: from two weeks for a simple site to several months for a catalogue with integrations. This is the only stage a developer estimates accurately.
Content, testing and launch: usually underestimated threefold. Text, photography, device checks, moving domains and mail.
What can run in parallel
Not everything is sequential, and this is where most of the time is saved.
Text is written alongside design, not after it. More than that — design built around real text comes out better than design that text is poured into later.
Photography and image preparation run alongside everything. They can start on day one, and rarely do.
Collecting access starts on the day of signature. Domain, mail, payment system, accounting system — all of it takes longer to sort out than expected and depends on nobody on the project.
Development after design, though, is almost always sequential: building an unapproved layout is a way of doing the work twice.
The longest part is not development
Look at completed projects and the largest share of time does not go on code.
It goes on waiting: for decisions, text, access, feedback. On a calendar it looks like weeks in which nothing happens, because one side is waiting for the other.
It is most visible during design approval. The layout went out on Tuesday, comments came back ten days later, and three of them contradict each other because two different people looked.
The cure is not pressure on the developer but a simple organisational decision: one person with the final word, and an agreed turnaround on feedback. Three working days on layout comments is a reasonable norm.
A project where feedback comes back in three days runs twice as fast as one where it comes back in a fortnight. For the same amount of work.
Three delays on the client's side
Named honestly, because this is where most of the slippage comes from.
Text. It gets postponed because writing is hard and the deadline looks distant. Then it turns out there is nothing to show without it. The fix is to write alongside and deliver page by page.
Approval by committee. Each extra participant adds not an opinion but a waiting cycle. If three people decide and meet fortnightly, every revision costs two weeks.
Access. Especially to payment and accounting systems, where documents and confirmations are required. Start on day one, not when it blocks.
Three delays on the developer's side
For symmetry — and so you know what to ask about.
Parallel projects. One person on three projects does not work three times faster: they switch, and every switch costs time. Ask up front what else your developer is on.
Underestimated integrations. Exchange with an outside system is almost always harder than the description suggests, because documentation is incomplete and test access takes a week to issue.
Holiday, illness, resignation. In a small team one person leaving is a stop. Asking what happens if the developer falls ill feels awkward, but it is cheaper than finding out mid-project.
Why we will do it in a week is sometimes true
Not every short timeline is a sign of a lack of seriousness.
A three-to-five-page site on a ready foundation, with your text and photography, genuinely goes together in a week. That is normal work and does not need padding out for the sake of gravitas.
A week stops being true the moment anything from the list appears: a catalogue, an account area, payments, exchange with an outside system, several languages, non-standard design.
Easy to check: ask what exactly will be done in that week and what is not included in it. The answer to the second question is the informative one.
How long a typical project takes
Reference points to work from. This is calendar time to launch, not person-hours.
A few-page brochure site: one to three weeks. The main variable is whether the text is ready.
A corporate site with service sections and a blog: six weeks to three months. Most of the time goes on content rather than development.
A catalogue or online shop: from three months. Data, filters, payment, delivery, exchange with an accounting system — each item adds weeks.
Migrating an existing site: add the work on old addresses to the development time. We had 673, and working through them took several days on its own.
How to shorten the timeline without losing quality
Four measures that genuinely work, unlike demanding that it be done faster.
Launch in parts. First what earns money: service pages and the form. Blog, gallery and the about section in a second release. The site starts working a month earlier.
Hand the text to a professional instead of writing it yourself. It is rarely more expensive than a month of delay and almost always faster.
Appoint one person with the final word. The cheapest acceleration available.
Reduce the number of states in the design: one product template instead of three, one form style instead of four. Every state is design, build and testing.
What money cannot speed up
Three things that move at their own pace regardless of budget.
Search indexing. After launch a search engine has to find the pages, crawl them and decide they deserve a place. That is weeks and months, and no payment shortens it.
Access issued by outside organisations. Banks, payment systems and domain registrars work to their own procedures.
Your own decision. If you are not sure what you want, adding people to the project accelerates only the spend. A week spent making up your mind saves a month of rework.
The week-two signs that the schedule will move
The signs appear early if you know where to look.
The brief is still not fixed in writing while work has already started. The scope will grow as it goes, and the timeline with it.
You took longer than three days to answer the developer's first question. That is your own pace, and it will not speed up on its own.
Text has not been started while design is already being shown. There will be no text by the build stage, and the project will stop exactly there.
None of these is fatal, but each costs roughly a week. Noticing them in week two is cheaper than in week eight.
Practical checklist
- Separate the development timeline from the time to launch in your calendar.
- Start collecting access credentials on the day of signature.
- Begin writing text alongside design rather than after it.
- Appoint one person with the final word.
- Agree a turnaround for comments on layouts and revisions.
- Ask what other projects your developer is currently on.
- Decide what can be moved to a second release.
Questions and answers
Why is the real timeline longer than the one quoted?
Because the developer counts their own work and not yours: approvals, text, photography, access to payment and accounting systems. That is about half the project. Development time and time to launch usually differ by around half again.
How long does a small brochure site take?
One to three weeks of calendar time. The main variable is whether text and photography are ready. If the material exists, a week is realistic; if it still has to be written and shot, that determines the timeline rather than development.
Can a project be sped up by adding people?
Rarely. Adding people helps where work can be divided and does not help where the bottleneck is a client decision or waiting for access. If you have not settled what you want, extra hands accelerate only the spend.
What can be moved to a second release?
Anything not involved in generating enquiries: the blog, the gallery, the detailed about section, additional language versions. Launch the service pages and the form first — the site starts working a month earlier and the rest follows without rush.
What are the week-two signs the schedule will move?
Three: the brief is still not fixed in writing while work has started; you took more than three days to answer the developer's first question; text has not been started while design is being shown. Each costs about a week, and noticing early is cheaper.