This deadlock breaks when someone converts “it isn’t finished” into a numbered list — because the standoff is never really about money, it’s about the absence of an agreed definition of done. Whoever writes the list first usually ends it.
Both positions are reasonable, which is why it lasts. You don’t want to pay for something incomplete. They don’t want to keep working unpaid on a list that grows each week.
The moment it happens
The final-10% standoff, when last payment and last change deadlock, has a recognisable stillness. Nobody is angry. The site is almost live. You’ve asked for a few things; they’ve asked for the balance. Two weeks pass with neither happening.
Complaint records show where it can end. One buyer reported 80% delivery, then paid in full, then got no response at all. Others describe being pushed to pay everything before completion despite agreeing to stages. The standoff resolves badly in both directions when nothing is written.
Why it forms
“Done” was never defined. With no deliverables list, completion is opinion. You can always name something outstanding; they can always call it a new request.
Remaining work is unpleasant. Form testing, mobile fixes, speed, connecting analytics. Small, fiddly, unsatisfying — and competing against new paid work.
Your list keeps growing. Each review finds something. From the vendor’s side, that reads as a moving finish line, and they slow down defensively.
Trust has thinned. You’re worried they’ll vanish once paid. They’re worried you’ll renegotiate at handover. Both fears are grounded in real market behaviour, and both produce the same paralysis.
Three ways out
1. The snag list (works most often). Write every outstanding item, numbered and specific — “contact form doesn’t deliver to my email”, not “forms not working”. Split into must-fix before launch and can-fix after. Send with a date: “These six before we go live on the 20th; the other nine after. Balance on go-live.” This gives the vendor a finite, payable task instead of an open-ended obligation.
2. Split the balance. Half on go-live, half after the after-launch list clears within a stated window. It costs you nothing, and it addresses their fear of unpaid tail work while keeping some leverage.
3. Launch first, fix after. Underused and often correct. If the essentials work — right phone number, working enquiry route, usable on a phone — go live with imperfections. A live site earns enquiries; a perfect unlaunched one earns nothing, and the remaining items become small maintenance tasks rather than blockers.
| Position | What it produces | Better move |
|---|---|---|
| “I’ll pay when it’s perfect” | Indefinite stall | Numbered must-fix list + date |
| “Pay in full, then I’ll finish” | Risk of post-payment silence | Split balance across go-live and snag clearance |
| Both waiting | Weeks of nothing | Whoever writes the list first breaks it |
What belongs on the must-fix list
Keep it short and defensible — defects, not preferences:
- Wrong phone number, address or business name
- Contact form not reaching you
- Broken or unusable on a phone
- Missing pages that customers need
- No visible way to call or message
Spacing you’d prefer different, a photo you want swapped, an extra service page — all after-launch. Treating preferences as blockers is what exhausted the relationship in the first place.
If they’ve already stopped responding
Then this is no longer a payment dispute. Ask in one message for the domain authorisation code, hosting login and the files as they stand. A 95%-complete site with access is genuinely finishable by someone else; without access, the next vendor will quote a rebuild.
What to do this week
- Write the numbered list yourself today. Don’t wait for it to be requested.
- Mark each item defect or preference. Be strict.
- Send the must-fix list with a launch date and confirm the balance is payable on go-live.
- Offer the split-balance option if trust is the real blocker.
- If nothing moves in a week, request domain, hosting and files in writing.
If you want it done the certain way
We define what “done” means before starting, so this standoff has nowhere to form — written scope, written date with a refund behind it, and the domain in your name. If your current project is six hours from finished, we’ll tell you to finish it rather than sell you a rebuild. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- The “90% done” website that never goes live
- Developer asking for more money mid-project?
- “Unlimited revisions” — does anyone mean it?
- Did they put your deadline in writing?
FAQ
Should I withhold the final payment until the website is perfect?
Withholding is reasonable leverage while work is genuinely incomplete, but “perfect” has no end point and creates deadlock. Withhold against a numbered must-fix list with a date instead.
Is it normal for a developer to want full payment before launch?
Some ask, usually because they fear renegotiation at handover. A split — part at go-live, part after the snag list clears — addresses that concern without you paying for unfinished work.
Can I launch a website with small issues outstanding?
Usually yes, and it’s often the better decision. If contact details are correct and the enquiry route works on a phone, launching converts the stall into maintenance.
