When the client says "this isn't what I asked for"
Every freelancer knows the moment. The work is delivered, the client goes quiet for two days, and then: "this isn't what I asked for." Sometimes they're right. Often they're not, and what they actually mean is "this isn
Every freelancer knows the moment. The work is delivered, the client goes quiet for two days, and then: "this isn't what I asked for."
Sometimes they're right. Often they're not, and what they actually mean is "this isn't what I imagined." Either way, the money is now stuck somewhere between two people who disagree about a document neither of them wrote down properly.
I've been reading through how the different dispute mechanisms actually work, because the interesting thing isn't who wins. It's what evidence each system is built to accept. Three of them are worth comparing properly.
1. Upwork fixed-price escrow
The client funds a milestone, the freelancer delivers, the client releases. If they don't, it goes to a dispute: support mediation first, and if that fails, binding arbitration through an outside provider with a filing fee attached.
What it's good at: context. A human reads the brief, the messages, the file history. Scope creep β the single most common freelance dispute β is a narrative problem, and narrative is exactly what human mediators handle better than anything automated.
What it costs you: time and money. Weeks, not minutes. The service fee comes off the top. And the outcome depends heavily on which person reads your ticket and how well you wrote it up.
2. Fiverr's resolution center
Similar shape, different bias. Buyer and seller can agree to cancel; if they can't, support decides. Commission is higher, and the decision tends to follow platform policy rather than the merits of the individual brief, because support is optimising for marketplace health, not for your particular argument.
3. PayPal disputes and chargebacks
This is the one freelancers underestimate. The dispute window is long, the process is buyer-weighted, and seller protection is weakest exactly where most freelancing lives: intangible deliverables. A client can receive a finished design, dispute the payment, and win, and your "evidence" is a chat log you exported from somewhere.
PayPal's advantage is that it works in fiat, in seconds, with no crypto literacy required. Its disadvantage is that "the buyer is unhappy" is frequently sufficient.
4. Criteria-first escrow (the Verdikta model)
A different primitive. Instead of adjudicating after a disagreement, the criteria are written and locked before the money moves: the creator funds an escrow contract and publishes success criteria plus a pass threshold. The rubric, threshold and deadline are fixed at creation β the creator can't edit or cancel them afterwards. A panel of AI models grades the submission against those criteria, and work that clears the threshold is paid automatically, without the creator's consent.
Two properties matter more than they sound:
- The creator cannot refuse to pay passing work. That removes the entire "client goes quiet" category of dispute.
- The escrow contract has no owner and takes no cut. No platform fee, no arbitration fee, no commission.
It also introduces a cost nobody quotes in the marketing: the hunter prepays an oracle fee per evaluation (roughly 0.00024 ETH at default settings, often less than a dollar), and if the submission fails, that prepay doesn't come back. It's a per-attempt cost, not a per-payout cost.
Where this genuinely breaks
I'd trust a comparison that only lists strengths about as far as I'd trust a client who says "just make it look nice." So, the weaknesses:
The rubric is the whole product, and writing one is hard. Most real freelance disputes aren't about checkable criteria. They're about scope: "I assumed revisions were included." A criteria-first system has no answer to ambiguity that was never resolved up front. If you can't express the deliverable as testable statements, this model doesn't apply, and pretending otherwise just moves the argument earlier.
No human appeal. The verdict is final. For a code review or a data-extraction task that's fine β correctness is checkable. For a brand voice, a design direction, or a piece of writing, a model can misread intent and there's no escalation path. That's a real cost, not a rounding error.
Earliest passing submission wins, not the best one. Payout order is submission order. Once one submission clears the bar, later and possibly better work is recorded as passed-but-unpaid. That's defensible for fairness (no queue-jumping by copying) but it rewards speed over quality, and it's a strange incentive for a system built on careful criteria.
All-or-nothing. There's no partial payment for partial work. Traditional escrow handles milestones; this handles one deliverable and one verdict.
No chargeback, in either direction. Great for the freelancer whose client gets buyer's remorse. Bad for the buyer whose passing submission turns out to be derivative, plagiarised, or produced by an agent that ignored half the rubric. There's no consumer-protection rail here, only a rubric.
Rubric-aware submissions. Any scoring system that publishes its criteria invites work optimised for the scorer rather than for the problem. Human reviewers are inconsistent, which is annoying, but inconsistency is also a defence.
So where does each one actually fit?
- Short, checkable, single-deliverable work (a function, a dataset, a transcript, a checklist): criteria-first escrow is genuinely better. Minutes instead of weeks, no platform cut, and the "client disappears" failure mode is designed out.
- Scope-heavy or taste-driven work (brand, design direction, long-form editorial): human mediation still wins, because the disagreement is about interpretation, not verification.
- High fraud risk in either direction: you still want the fiat rails and their chargeback machinery, with all their flaws.
The honest summary is that this isn't a better Upwork. It's a narrower instrument that solves one specific failure β the unresponsive client β very well, by making payment conditional on published criteria instead of on a human's mood. The price of that is every dispute that criteria can't express.
Genuine question for anyone who's run work through a system like this: did writing the rubric up front change what you delivered, or just how you described it afterwards?
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.