Escrow solves one specific problem — committing to pay a stranger before you have seen the work — and it is worth knowing exactly what it does on LanceGuru today, because funding a milestone records the commitment rather than collecting the money. How to split a project into milestones both sides can judge, write one acceptance criterion each, reject a deliverable well, and what evidence decides a dispute.
You are about to commit money to someone you have never met, for work that does not exist yet. That is the problem milestones and escrow exist to reduce, and it is worth knowing exactly how much of it they remove — on LanceGuru today, funding a milestone records a commitment rather than collecting a payment, and a great deal of frustration comes from assuming otherwise. What the mechanism also cannot do is make a badly scoped project succeed. This guide covers what a funded milestone actually is here, the three risks it leaves with you, how to break a project into milestones that can be judged rather than argued about, and how to handle the two moments people get wrong: funding versus releasing, and rejecting a deliverable.
What a funded milestone actually is here
The structure is a commitment step placed before the work instead of after it. You agree an amount against one named deliverable and fund that milestone; the freelancer can see it is funded, so they know what they are owed and for what; you keep the release, so the amount only becomes theirs once you have approved what arrived. That ordering is the whole idea, and it removes the single largest reason freelance deals fall apart before they start: neither party wanting to move first.
Now the part to be explicit about, because the word “escrow” implies more than is true today. Funding a milestone on LanceGuru records your commitment inside the project. It does not yet charge your card or UPI and hand the money to a payment provider to hold. Live payment collection is a switch the platform has not turned on, so what exists today is the agreement, dated and itemised, rather than a settled transfer sitting with a third party. Releasing a milestone credits the freelancer's LanceGuru balance, which they then withdraw from. If you were expecting your bank to be debited at the funding step, it will not be — and you should not let a freelancer believe otherwise either.
What the mechanism does give you, and gives you now, is the record. The scope, the funding, the delivery and the release all sit inside the project, so there is a timestamped account of what was agreed, when, and against which deliverable. That record is what a dispute is decided on, it is what lets a capable freelancer with no reviews yet start without demanding a large advance, and it is the part that decides whether a project goes well — none of which depends on which day the money moves. Everything below works the same way either way. The end-to-end sequence is laid out on the how it works page.
Splitting a project into milestones both sides can judge
A milestone is only useful if a reasonable outsider could look at the output and say yes or no. That single test rules out most of the milestones people actually write. “Backend development — 40%” fails it: there is no artefact, so completion becomes a matter of opinion. “A working staging link where I can register an account, log in, and see my order history” passes it, because either you can do those three things or you cannot.
Aim for three to five milestones on a project of a few weeks. Fewer than three and you lose the early exit point that is half the value; more than six and you spend your life reviewing. Make the first one small and early — it is your cheapest possible test of whether this working relationship is going to function, and it is worth structuring the project so you learn that in week one rather than week five.
| Pattern | Milestones | Fits |
|---|---|---|
| Design, build, launch | Approved design → working build on a staging link → live with handover complete | Websites, apps, anything with a visual approval step before construction |
| Sprint-based | A fixed period of work with an agreed list of outcomes, repeated | Ongoing development where priorities genuinely shift between cycles |
| Per-asset | One milestone per deliverable: each article, each video, each set of illustrations | Content and creative work produced in batches |
| Retainer | A monthly milestone against a stated scope and a response time | Maintenance and support, where there is no finish line to pay against |
One acceptance criterion per milestone, written before work starts
This is the highest-value ten minutes in the entire project. For each milestone, write the single test you will run when it is delivered. Not a description of the work — the test. “I will open the staging link on my phone and place a test order with a test card, and receive the confirmation email.” “I will read the five articles and check each one covers the brief's three points and is over 800 words.”
Writing it beforehand does two useful things. It forces you to discover, while it is still cheap, that you and the freelancer had different pictures in your heads — that conversation in week zero costs an hour and in week four costs the project. And it means that when the work arrives, acceptance is a check rather than a judgement, so you are not trying to decide whether you feel satisfied while someone waits on your answer.
Funding and releasing are two different moments
This is where most first-time confusion sits, and it is worth being precise. Funding a milestone is you committing, on the record, to pay a stated amount for a stated deliverable. It happens before the work. Releasing is you letting that amount go to the freelancer, and it happens after the work, when you have run your acceptance test. Two separate decisions, in that order.
Fund early and release on merit. Funding late — or leaving a milestone unfunded while the freelancer works — undoes the whole point of the arrangement: there is then nothing on the record at all, and you are asking someone to work on a verbal promise, which is exactly what a professional will decline or price for. Releasing early, on the other hand, is the mistake generous clients make. It feels like good faith, and it quietly removes your only leverage at the moment you might need it. Neither of these is about distrust; they are about keeping the structure you both agreed to, so that neither side has to rely on the other's goodwill.
How to reject a deliverable well
Rejecting a milestone is a normal event, not a hostile one, and how you do it largely determines what happens next. A rejection that says “this isn't what I wanted” gives the freelancer nothing to act on and invites a defensive reply. A rejection that names the criterion, states what failed and asks for one specific change gets you a fix.
Thanks for sending this. Checking it against what we agreed for this milestone: the order confirmation email isn't arriving, and on my phone the product images overflow the screen in portrait. The rest matches. Could you fix those two and resend? Happy to get on a call if either one is more complicated than it looks.
Three things make that work. It references the agreed criterion rather than a new preference. It separates what failed from what passed, so the freelancer knows not to rebuild everything. And it offers a conversation, which matters because sometimes “the email isn't arriving” is your spam filter. Keep the exchange in the project's messages rather than moving it to a private channel — not out of suspicion, but because if this does end up in a dispute, the written record of what was asked and when is the thing that decides it.
One more habit: give feedback in one consolidated round rather than as it occurs to you. Five separate messages over two days, each adding a new point, is the most common way a client accidentally doubles the work on a milestone and then wonders why the date slipped. Feedback, check-in rhythm and what to do about a missed deadline are a subject in their own right, and they are covered in how to manage a freelance project without micromanaging.
If it becomes a dispute
Most projects never get here, and most that do resolve in the conversation before anything formal starts. If one is genuinely stuck, a dispute moves the decision to the platform, and what decides it is evidence rather than argument. That is worth knowing in advance, because it tells you what to do during the project rather than at the end of it.
- The agreed scope and acceptance criteria, written down before the work started. This is almost always the decisive document, which is why the ten minutes spent writing it is the best-spent time in the project.
- The messages, in order. What was asked for, what was promised, when. Conversations held off-platform simply do not exist as evidence.
- What was actually delivered, and when — files, links, commits, drafts.
- The revision history. Whether feedback was given, whether it was acted on, and how many rounds have already happened.
Note what is missing from that list: how either party feels about the other. A dispute compares what was delivered against what was agreed, so if nothing was agreed in writing there is very little to compare. That is the practical argument for a short scope of work even on a small project — the clauses worth naming are set out in the freelance contract and scope of work checklist, which is written for freelancers but is exactly the document you want to receive as a client. If you need help with a stuck project, start at the help centre and contact support from there.
Four mistakes worth avoiding
Each of these is comfortable in the moment and expensive later.
- One giant milestone for the whole project. You have recreated the problem escrow was meant to solve, with a single all-or-nothing decision at the end and no early exit.
- Releasing early to be nice. A release is final, and once it is done so is the structure. Be generous with your praise and your review, not with the release button.
- Paying outside the platform because someone suggests it is simpler or cheaper. You lose the milestone record, the review, and any route to a dispute. A request to move the money off-platform before any work is agreed is one of the most reliable warning signs there is.
- Milestones with no criteria. “Phase 2 — 30%” is a date with a price attached, not a milestone. When it arrives, neither of you will know whether it is complete.
Write the milestones and their acceptance tests into the brief, and the proposals you receive on the projects board will be priced against the same understanding you have.
Post a project with milestonesThe takeaway: the milestone structure addresses exactly one problem — neither side wanting to move first — and leaves bad scope, a bad hire and your own delays with you. Funding a milestone here records your commitment against a named deliverable rather than charging your card, so the value is in the agreement and the record. Spend the effort where it works: three to five milestones that produce something a stranger could judge, one written acceptance test each, a small first milestone as your cheapest trial, fund early and release only on merit. Reject by naming the criterion and the specific failure, keep every exchange in the project record, and never let anyone move the money off-platform.