A reason for delay is fine; a reason that arrives without a new date is a stall. That single test separates almost every genuine explanation from an evasion, and it saves you from arguing about whether the cousin’s wedding was real.
The moment it happens
Festival, exam, “another client” — the excuse playbook of late web developers becomes visible around the third one. Individually each was plausible. Together they form a pattern, and you start keeping a mental tally instead of a project schedule.
The frustrating part is that you can’t disprove any of them. You weren’t at the wedding. You can’t audit their server. So you accept it, wait, and the same thing happens next week.
The field guide
Not all of these are lies. Some are the ordinary friction of a one-person business. What distinguishes them is whether a new commitment comes attached.
| What you hear | Often genuine when… | Probably a stall when… |
|---|---|---|
| “Festival / wedding / family function” | Named, dated, with a return date given upfront | Recurring, or announced only after you chase |
| “Exam” | Stated at the start of the project | Appears in week five as a surprise |
| “Another client’s urgent work” | Once, with a specific new date | Repeated — it means you’re the low-priority job |
| “Server problem” | Something is actually broken and visible | Nothing is visible either way |
| “Designer left the team” | Followed by a revised plan | Followed by silence |
| “Waiting for your content” | You genuinely haven’t sent it | You sent it and can prove the date |
| “It’s 90% done” | Accompanied by a link | Said for the third week running |
| “Technical issue with the theme” | Explained in one specific sentence | Explained in jargon you can’t check |
Read the right-hand column as a scoring system, not a verdict. One entry is a bad week. Four is your answer.
The reply that works on both
You don’t need to challenge the reason. Challenging it puts you in an argument you can’t win and makes you the difficult client, which is the outcome they’d prefer.
Instead, accept the reason and ask for the consequence:
Understood. Given that, what’s the new date for [specific deliverable], and can you send the staging link so I can see where it is now?
This works because it’s polite, unarguable, and diagnostic. A developer who is behind but working will give you a date and a link. A developer who is stalling will give you neither, and now that’s on record in writing.
Keep a list, not a feeling
Open a note on your phone and log four columns: date, what was promised, what arrived, reason given. Two minutes a week.
Three things come of it. You stop wondering whether you’re being unreasonable — the list either shows a pattern or it doesn’t. You can quote specifics instead of complaining generally, which changes how the conversation goes. And if this ends in a refund request, a consumer complaint, or a legal notice, a dated log of promises against deliveries is the strongest document you’ll have.
When to stop asking and start escalating
Move on from the polite request when any of these is true:
- Three reasons, no new dates. The pattern is now established.
- A date has been revised twice. The estimate was never real.
- More money is requested before anything viewable exists. This one is serious enough to stop payments over.
- Replies have moved from minutes to days, and then to only after you follow up twice.
At that point the useful step isn’t a better message — it’s a written escalation with a deadline, and a decision about whether to keep going.
The fair version of this
Some genuinely capable developers are badly organised, not dishonest. They will finish, late, and the work will be good. If you have seen real progress on a link, and the delay is honest and communicated, the sensible move is to extend the timeline in writing rather than switch — switching mid-build carries its own cost and delay.
The distinction is progress you can see. Excuses attached to visible work are inconvenient. Excuses attached to nothing are the problem.
What to do this week
- Start the four-column log, backdated from memory as best you can.
- Send the accept-and-ask-for-a-date message.
- Ask for the staging link in the same message.
- Count the reasons given so far without a revised date.
- Hold any further payment until something viewable exists.
If you want it done the certain way
If you’re three excuses in with nothing to open, send us the link or the last WhatsApp thread and we’ll tell you honestly whether the site is nearly done or barely started. We give dates in writing and a link you can check, so a delay is something you see rather than something explained to you. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- “2 din mein ho jayega” — the delay loop
- Your developer is ignoring you: the escalation ladder
- When replies go from minutes to days
- Can you see your website being built?
FAQ
How do I know if my developer’s delay reason is genuine?
Judge the reply, not the reason. A genuine delay comes with a revised date and something viewable; a stall comes with neither. Count how many reasons you’ve received without a new date attached.
What should I say when a developer keeps making excuses?
Accept the reason and ask for the consequence: the new date for a named deliverable, plus the staging link. It avoids an argument and produces either an answer or a pattern on record.
Should I switch developers because of repeated delays?
Not automatically. If you can see real progress on a link, extending the timeline in writing is usually cheaper than switching. If nothing viewable exists after repeated promises, switching becomes the lower-risk option.
