A delay becomes a dead project at the point where you can no longer see new work — not at the point where the deadline passes. That is the test worth applying, because “two more days” repeated four times is a different situation from a genuine two-day overrun, and the two need different responses.
If your developer has been saying “bas 2 din aur” for three weeks, this page separates the two, then gives you the message that usually ends the loop.
The moment it happens
“2 Din Mein Ho Jayega” — the website delay loop that never ends rarely announces itself. Each individual promise is reasonable. It is only when you scroll up in the chat that you notice the same sentence in three different weeks.
Buyers on India’s complaint forums describe where this ends. One wrote that a project with a 10–15 day deadline took 40 days and was still half done. Another paid ₹12,900 in full and reported five months later that the site still wasn’t working. A third described 80% delivery, full payment, and then no response at all.
None of those started with a refusal. They started with a delay that sounded ordinary.
Why this keeps happening
The deadline was never a commitment. In most small website deals the date is spoken, not written. A verbal date has no consequence attached, so it competes with every other client’s verbal date — and loses to whoever is shouting loudest that week.
Your project is one of many, and yours is the cheapest. A developer juggling several builds will service the client who pays most or complains most. If your quote was at the bottom of the market, you are structurally last in the queue. That isn’t malice; it’s arithmetic.
Nobody agreed on what “done” means. Without a written deliverables list, “finished” is a matter of opinion, so the project can sit at 90% forever. The last 10% is where most abandoned websites die.
Sometimes the delay is yours. This is worth saying plainly because it is common and rarely admitted: a large share of stalled projects are waiting on the client’s logo, photos or page text. If the last thing you sent was “will share content on Sunday” three Sundays ago, the developer is not the blocker. We don’t have a reliable market-wide figure for how often each side causes the stall — but before escalating, check the chat and be honest about who is waiting for whom.
Recoverable delay vs dead project
| Signal | Recoverable delay | Dead project |
|---|---|---|
| New work visible | You can see changes on a link or screenshots week to week | Nothing new for 2+ weeks, only assurances |
| Reply pattern | Answers within a day, gives specifics | Answers only after several pings, always vague |
| Specificity | Names what’s pending (“payment gateway testing”) | “Almost done”, “final touches” repeated |
| Money | No new demands | Asks for more money to “continue” |
| Access | Willing to show a staging link | Avoids showing anything until “it’s ready” |
If you’re in the right-hand column on three or more rows, treat it as a dead project and switch from chasing to closing.
The message that ends the loop
Vague pressure produces vague promises. A dated request with one named deliverable produces either work or a real answer. Send this, once:
Please confirm two things in writing by [date, 3 days out]: (1) the link where I can see the current work, and (2) the date the site goes live. If either isn’t possible, tell me now and we’ll settle what’s been done and part ways.
Two things make it work. It asks for a link, which cannot be faked with reassurance. And it offers an exit, which removes the incentive to keep stalling to avoid a confrontation.
If the reply is another promise with no link, you have your answer, and the advance-recovery steps become the relevant path.
What to do this week
- Scroll to the top of the chat and write down the original promised date. Most people misremember it as later than it was.
- Check who sent the last piece of pending content. If it’s your turn, send it today before escalating anything.
- Ask for a staging link — not a screenshot. A link is the only proof that work exists.
- Send the dated confirmation message above, once, and stop sending daily pings; they lower your pressure, not raise it.
- If you restart with anyone, put the deadline and the deliverables list on one page before paying. A date with a consequence behaves completely differently from a date without one.
If you want it done the certain way
We publish our prices, put the delivery date in writing with a refund behind it, and hand over the domain and logins in your name. If your current project is closer to finished than it feels, we’ll say so — restarting is not always the right advice. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- The “90% done” website that never goes live
- When your developer’s replies go from minutes to days
- Developer took the advance and vanished: recovery steps
- Cheated once? The safe-rebuild guide
FAQ
How late is too late for a small business website?
For a standard 5–8 page site, a week or two beyond the promised date is an overrun; a month with no visible new work is a stalled project. The useful measure is visible progress, not elapsed days.
Should I stop paying to force progress?
Withholding the final payment is reasonable leverage once work has stopped, but it often creates a standoff where neither side moves. Milestone payments agreed upfront prevent this better than withholding later.
Can I take the half-finished site to another developer?
Usually yes, if you have the domain, hosting access and files. Ask for all three in one written message. Without them, a new developer is often faster starting fresh than untangling someone else’s half-built work.
