Websites rarely fail at the start — they stall at almost-finished, because “done” was never defined and the remaining work is a vague list nobody has written down. The fix is unglamorous: convert “the last bit” into a numbered snag list with a launch date, and launch with items still open if necessary.
Buyers describe this state in near-identical terms. One reported 80% delivery, full payment made, and then no response. Another was at 50% completion 40 days into what was quoted as a 10–15 day project. The site exists. It just never goes live.
The moment it happens
The “90% done” website that never actually goes live has a specific texture: nothing is wrong enough to complain about.
The design is approved. Most pages are there. The developer says the remaining work is small — a form to connect, some text to place, one page to finish. Each week that’s still true. Nobody is angry, nobody has walked away, and the site has been almost ready since last month.
Why the last 10% is where projects die
Nobody wrote down what “finished” means. Without a deliverables list, completion is a matter of opinion, and opinions can be revised indefinitely. This is the root cause of most of them.
The remaining work is the boring work. Form testing, mobile fixes, page speed, favicon, contact details, connecting analytics. None of it is satisfying, all of it is fiddly, and it competes against new projects that are more interesting and better paid.
The economics have already resolved. If most of the money is paid, the incentive to spend another two hours has weakened. If money is being withheld, the vendor is now working unpaid and slows further. Both directions produce the same stall.
Both sides keep adding. You spot something to change; they mention something they’d like to improve. The finish line moves every week by mutual agreement.
Sometimes it’s the owner. This is worth naming plainly: a project can sit at 95% because the owner keeps requesting one more change, or hasn’t approved the final version, or hasn’t sent the last two photos. If the last message in the thread is a question waiting on you, the stall is yours to release.
The snag-list method
This works because it replaces an argument about completion with a countable list.
- Open the site and write down every single thing that isn’t right. Number them. Be specific: “contact form doesn’t deliver to my email”, not “forms not working properly”.
- Split the list into two: must-fix before launch and can-fix after launch. Most items belong in the second group — a live site with three imperfections beats a perfect unlaunched one.
- Send the must-fix list with a launch date. One message: “These 6 items before we go live on the 20th. The other 9 can follow after.”
- Launch on the date, with the after-list open. This is the step people resist and the step that ends the stall. Once the site is live, remaining items become small maintenance tasks instead of blockers.
- Pay against the must-fix list, not against a feeling of completeness.
| Belongs in must-fix | Belongs in after-launch |
|---|---|
| Contact form doesn’t reach you | Some spacing looks off on desktop |
| Wrong phone number or address | A photo you’d like to swap |
| Broken on a phone | An extra service page |
| No way to call or WhatsApp | Blog section not set up |
| Pages missing that customers need | Minor wording preferences |
If the vendor has stopped responding entirely
Then this is no longer a completion problem. Ask, in one written message, for the domain authorisation code, hosting login and the files as they stand. A 90%-complete site plus your domain is genuinely worth something — most developers can finish someone else’s near-complete build, and you avoid starting over. Without those three items, the next vendor will quote a rebuild, because untangling inaccessible work costs more than replacing it.
What to do this week
- Write the numbered snag list yourself today. Nobody else will.
- Split it into must-fix and after-launch, honestly — the must-fix list should be short.
- Send it with a launch date, once, and stop adding new items until after go-live.
- Check whether anything on the list is waiting on you. Clear those first; it removes the excuse.
- If there’s no response in a week, request domain, hosting and files in writing and plan around finishing it elsewhere.
If you want it done the certain way
If you have a nearly-finished site, bring it — sometimes the honest answer is that it needs six hours of work rather than a rebuild, and we’ll tell you that. When we build, the delivery date is written with a refund behind it, and the domain and logins sit in your name so a stall can never trap the project. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- “2 din mein ho jayega”: breaking the website delay loop
- The final-payment standoff: when last payment and last change deadlock
- Did they put your deadline in writing?
- Cheated once? The safe-rebuild guide
FAQ
Should I launch a website that isn’t completely finished?
Usually yes, if the essentials work — correct contact details, working enquiry route, usable on a phone. A live site with minor flaws earns you enquiries; a perfect unlaunched one earns nothing.
How do I get a developer to finish the last bit?
Replace “please finish” with a numbered must-fix list and a launch date. Vague completeness requests produce vague replies; a countable list with a date produces either work or a clear answer.
Can another developer complete a half-built website?
Often, provided you have hosting access, admin login and the files. Without access most will quote a fresh build instead, because inheriting inaccessible work is riskier than starting clean.
