Why this exists
The single biggest fear on either side of a freelance job is the same fear, mirrored: the client is afraid of paying for work that never arrives; the Smith is afraid of doing work that never gets paid for. Smith's payment structure exists specifically to remove that fear from both directions at once — but only if you actually use it the way it's designed to be used.
How the flow actually works
1. Funds are secured before work starts. A client needs a verified payment method before a job can go live and start receiving proposals. Once a proposal is accepted, payment is collected upfront and held — the Smith isn't working speculatively, and the client isn't handing money to someone who hasn't committed to the job yet.
2. Work is delivered through the Submit flow, not through chat. When a Smith finishes (or finishes a round), they submit deliverables through the job's Submit action — this is what actually starts the review clock. Saying "it's done" in a message doesn't; hitting Submit does. This matters because it's the one unambiguous signal both sides can point back to later.
3. The client has a real review window. Once work is submitted, the client has time to review it. If changes are needed, "Request Changes" sends it back with a note — that's a normal, expected part of the process, not a confrontation. If the client doesn't respond within the review window, the work auto-accepts — this protects Smiths from a client who simply goes quiet after delivery.
4. Payout has a hold period after acceptance. Once work is accepted (by the client or automatically), there's a hold period before funds release to the Smith. This exists specifically so that if something surfaces right after acceptance, there's still time to raise it.
Break big jobs into milestones
For jobs $500 and up, don't fund it as one giant lump. Structure it as milestones — each with its own description, acceptance criteria, and amount. This isn't extra bureaucracy, it's the single best protection either side has on a larger job:
- For clients: you're not funding the whole project against a single, distant "done." Each milestone is a checkpoint where you confirm the work is on track before more money moves.
- For Smiths: you're not carrying the risk of a large job falling apart halfway through with nothing to show for it. Each completed milestone is paid on its own, independent of what happens with the rest of the job.
A good milestone has a specific, checkable acceptance criterion — not "backend work" but "user auth working end-to-end: signup, login, session persistence, and password reset all functional." If you can't tell whether a milestone is done just by looking at the criteria, rewrite the criteria before you start the work, not after.
Common mistakes on both sides
Clients: posting a job and trying to arrange payment outside the platform "to save on fees" — this removes every protection described above, for both of you. Also: agreeing to scope changes in conversation without confirming them as part of the actual milestone/job scope, which sets up exactly the "that wasn't what we agreed" disagreement later.
Smiths: starting work before a proposal is formally accepted and funded — if a client asks you to "just get started" before the funding step, that's unpaid, unprotected work, no matter how reasonable it sounds in the moment. Also: delivering final work through a message instead of the Submit flow, which means the review clock never starts and there's no clear record that delivery happened.
If there's a real disagreement
Request Changes exists for the normal back-and-forth of revisions — it's not a big deal and most jobs use it at least once. If a disagreement is more fundamental than a revision (the work doesn't match what was scoped, or payment is being withheld without cause), that's what disputes are for — and exactly why everything above matters: a dispute is only as strong as the record behind it. Funded milestones with clear acceptance criteria and a job thread that shows what was actually agreed is the entire difference between a dispute that resolves quickly and one that doesn't resolve at all.
The short version
Fund before work starts. Submit through the Submit button, not a message. Use milestones on anything over $500, with acceptance criteria specific enough that "done" isn't a judgment call. Do those three things and most disputes never happen in the first place — because there's nothing left to disagree about.