Realistic timelines by project type, what causes delays, and how to keep a project on schedule.
Timelines slip on most web projects, and almost always for the same reason. It is rarely the development.
Realistic timelines
| Project | Typical duration | Assuming |
|---|---|---|
| Brochure site, five to eight pages | Three to four weeks | Content ready at kickoff |
| Site with CMS and custom design | Six to eight weeks | Two rounds of design review |
| Ecommerce store | Eight to twelve weeks | Product data supplied in usable form |
| Mobile app, first version | Three to six months | Scope fixed before starting |
Where the time actually goes
On a typical four week website, development is often less than half of it. The rest is design review cycles, content, and the approval steps between them.
The three causes of delay
- Content arriving late. By a wide margin the most common cause.
- Decision bottlenecks. If approval needs someone who is travelling, the project waits.
- Scope growth. Each 'while we are at it' addition is reasonable alone and collectively adds weeks.
How to keep it on track
- Deliver all content before the build starts, not during
- Agree review turnaround times in advance. Two business days is reasonable.
- Keep a list of ideas that are explicitly for version two
- Book the launch date at kickoff so everyone works toward the same day
What a compressed timeline actually costs
It is possible to build faster, and it costs money in overtime or in quality. What it cannot do is skip your review cycles. A studio can compress its own work but cannot compress the time you take to approve things, so the fastest projects are the ones where the client is fastest.