Freelance Delivery & Acceptance Guide

To the freelancer, the work is done: written, tested, delivered. To the client, nothing is finished yet — “let me take a look”, “let me check with the team”, “let me try it for a few days” begins, and it carries no end date.

The cause is usually not bad faith but a lack of clarity: the contract says “payment on completion”, but there's no concrete, measurable definition of what “complete” means. Until one side fills that gap, both feel justified.

An acceptance criterion is an objective, verifiable statement that has to be true for the work to count as done. “Make it look nice” is not an acceptance criterion; “the payment form must accept Visa, Mastercard and Troy cards” is.

A good criterion has three properties: it's measurable (answerable yes/no), it's written before delivery, and it carries both parties' sign-off. Adding or changing a criterion after the contract is signed shifts the ground both sides agreed to stand on.

You don't need technical knowledge to write one — what matters is stating clearly what is wanted; deciding how to verify it is the verifier's job.

Share a staging URL or a link the client can actually try — “I sent the source code” isn't enough if the client can't run it themselves.

Check off the criteria list one by one: what was met, what wasn't, what fell out of scope. A blanket “everything's done” proves nothing once a dispute starts.

Timestamp the moment of delivery. A later argument over when something was delivered is the real source behind most disputes — before who was right even comes up.

Go back to the criteria list first. Is the disagreement about one of the listed criteria, or a new request that was never in it? If it's the latter, that's a revision request — not a rejection of the original delivery.

If the two sides can't agree, bring in an independent third eye. The key word is independent: not the delivering side's own judgment, and not the requesting side's unilateral decision — a neutral check against the criteria both sides already signed.

There has to be a time limit. An objection window left open indefinitely turns, in practice, into a right to never pay — a protection just as important as writing the criteria in the first place, only this time it protects the freelancer.

The clause says: if no explicit objection arrives within an agreed window after delivery, the work counts as accepted. It isn't complicated — it just refuses to let either side say “I'm still looking at it” forever.

It isn't there to rush the client; the window is reasonable and known in advance. The point is that review has a deadline, the same way delivery does.

The clause only works under two conditions: the window is known to both sides ahead of time, and the moment of delivery is recorded beyond dispute. Without either, it stays a sentence on paper.

Lancerix represents the criteria here, not either party: it verifies whether the acceptance criteria written into the contract were met, without favoring either side, and writes the result into a timestamped, unchangeable report.

It is not an escrow service — money never passes through Lancerix; payment is settled directly between the parties. It is not a legal service — it provides a contract template with acceptance criteria built in, not legal counsel. And it is not a security audit — it verifies the criteria that were written, not a penetration test or a guarantee of bug-free code.

Being this explicit about the boundaries is deliberate: when what's being verified is unclear, the verification itself becomes a new source of dispute.