Treat any quoted website timeline as the best case and plan for roughly double — and understand that a meaningful share of the overrun will be caused by your side, not the developer’s. The number in the quotation is a sales figure; the number that matters is what happens after content is due.
The moment it happens
How late do website projects actually run in India is a question you only ask after the first missed date. Before that, fifteen days sounded like fifteen days.
One buyer’s public account puts the shape of it plainly: forty days in, the site was described as roughly half finished, against a much shorter promise. That’s a single case rather than a market statistic, but the pattern behind it is consistent — the schedule doesn’t slip all at once. It slips a week at a time, always for a reason that sounds reasonable.
Where the time actually goes
A small business website has roughly five phases. The delay concentrates in two of them.
| Phase | Realistic duration | Who controls it | Delay risk |
|---|---|---|---|
| Requirements and structure | 2–4 days | Both | Low |
| Design of the main pages | 4–7 days | Developer | Moderate |
| Content — text, photos, logo | Anywhere from 2 days to never | You | Highest |
| Build and page assembly | 5–10 days | Developer | Moderate |
| Revisions, testing, go-live | 3–7 days | Both | Moderate |
The third row is where most projects die. A developer can build the design in a week and then wait eleven weeks for your product photographs. That delay appears in your memory as the developer being slow, and in theirs as you being unreachable. Both are partly right.
The fifth row is the second sink. Revision rounds have no natural end unless somebody defines one.
Which delays are genuinely the developer’s fault
To be even-handed, because both kinds exist:
Theirs: taking on more projects than they can staff; disappearing for days; quoting a fortnight for something that was never a fortnight’s work; rebuilding the same page three times because they never asked what you wanted.
Yours: content that arrives in pieces over six weeks; feedback given as “make it better”; approval waiting on a relative who’s travelling; changing the business’s positioning halfway through.
Neither: a payment gateway’s verification queue, a domain transfer window, a bank’s merchant approval. These are real and nobody can compress them.
Knowing which category you’re in changes what you should do. Chasing harder doesn’t fix a content stall.
Reading a slipping project early
Three signals, in the order they appear:
- The second date moves. A first slip is normal. When the revised date also slips, the original estimate was wrong, not the execution.
- Updates become descriptions instead of links. “Working on it” replaces “here’s the page.” A build in progress can always be shown.
- You are asked for money before you are shown progress. A mid-project payment request that arrives before a viewable stage is a bad sign in itself.
How to compress it from your side
Most of the available speed is on your desk:
- Send all content before the build begins. Text for every page, photographs, logo file, and the exact phone number and address you want shown. Projects where content is ready at the start finish close to their quoted date.
- Nominate one decision-maker. One person approves. Others may comment.
- Give feedback in a single numbered list per round, not as messages across three days.
- Agree the number of revision rounds in writing before work starts.
- Ask for a staging link on day one so you’re watching rather than waiting.
What to put in writing before you pay
Four lines, in whatever medium you’re using:
- A date for each phase, not just a final delivery date.
- What happens if content is late from your side — usually the timeline extends, which is fair.
- The number of revision rounds included.
- What “delivered” means: live on your domain, with your logins handed over.
That fourth line prevents the most common ending, where a project is described as finished but nothing is live.
What to do this week
- Write down which phase your project is actually in.
- Gather every remaining piece of content and send it in one batch.
- Ask for a staging link if you don’t have one.
- Request a phase-by-phase revised date in writing.
- If the second revised date has already slipped, read the escalation ladder before paying anything more.
If you want it done the certain way
We quote a date and publish what we need from you to hold it — because a timeline that ignores content is fiction. You get a staging link from the first build day, so the schedule is something you can see rather than something you’re told about. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- “2 din mein ho jayega” — the delay loop
- The “90% done” website that never goes live
- How often should a developer update you?
- The content stall that delays most websites
FAQ
How long should a small business website take?
A straightforward five-to-eight page site is realistically two to four weeks once content is ready. Quotes of a few days usually assume text and photographs already exist and no revision rounds.
Is my website late because of the developer or because of me?
Check which phase you’re in. If the design is done and the build is waiting on your text or photographs, the delay is content-side and chasing won’t move it. If you’ve sent everything and nothing is visible, it’s execution-side.
What should I do when a promised delivery date passes?
Ask for a revised date broken down by phase, plus a staging link. A second slip against a revised date usually means the estimate was never achievable, which changes how you plan the rest of the project.
