Acceptance Criteria for Freelance Software Projects: Examples You Can Copy

Acceptance criteria do one thing: they move the disagreement from delivery day, when it costs everything, to day 3, when it costs nothing. Every project has a gap between what the client pictured and what the developer heard. The only choice is when you discover it.

The symptoms of a missing definition of done are familiar to anyone who has hired developers: the demo that works on the freelancer’s machine and nowhere else, the "edge case" that turns out to be the main case, the version 2 invoice for things the client thought were in version 1, and the slow-motion argument conducted through milestone disputes on a platform.

The fix is not a longer contract. It is two short documents in plain language: a scope section that says what is in and, explicitly, what is out, and a numbered list of acceptance tests that define done as observable behavior rather than a feeling.

Write scope as sentences a non-technical person can read aloud. The IN list is what everyone focuses on, but the OUT list is what saves the project: it is where mismatched assumptions go to die before they are expensive.

Note what the example below does: it names the known risk (a site behind aggressive bot protection) on day one and prices the uncertainty into the plan, instead of discovering it in week two and renegotiating under pressure.

A good acceptance test has three properties. It is observable: it describes something that happens, not a quality the code has. It is verifiable by a non-developer: the client can run the check themselves without reading code. And it covers failure, not just success, because how software behaves when the world changes is most of what you are buying.

The set below is the actual format from our scraper spec. AT-3 deserves attention: it is silent-failure insurance. The expensive version of a broken scraper is not the one that stops, it is the one that keeps writing wrong data with confidence. An acceptance test that requires the system to announce its own breakage is worth more than five tests of the happy path.

The pattern transfers to any project type. Here is the same discipline applied to a different common freelance job, connecting a client’s order system to a shipping provider’s API, so you can see which parts are structural and which are project-specific.

Structural in both sets: an end-to-end happy path with concrete numbers, a failure-mode test, a recovery test, and a handover test. Project-specific: everything else. Write your own set by asking one question per risk: "what would I check on delivery day to know this risk did not materialize?" Then move that check to the spec.

Acceptance criteria earn their keep when payment references them. Fixed price beats hourly for well-specified small projects precisely because the spec carries the definition of done; each milestone names which acceptance tests it satisfies, and payment for that milestone follows written acceptance against those tests.

From the scraper example: milestone 1 (day 5) covered sites 1 to 3, storage, and a manual run, satisfying AT-1 for those sites, with $290 of the balance due on written acceptance. Milestone 2 (day 9) covered the remaining sites including the documented Cloudflare fallback, the scheduler and the digest, satisfying AT-2 and AT-3, with $310 due. The deposit credited against milestone 1; total fixed at $1,090, agreed before any code.

The structure protects both sides. The client never pays for undefined work; the freelancer never argues about whether work is done, because "done" was numbered. If you are the client and a freelancer resists acceptance tests, that is signal. If you are the freelancer and the client cannot agree on them, you have discovered the project’s real risk early and for free.

Code that works on the developer’s machine, with no docs and no deploy notes, is a future invoice. The handover document is the last acceptance criterion, and AT-4 in the scraper set ("fresh-machine setup in under 15 minutes by a non-developer") exists to make it testable.

A real handover contains: setup as numbered commands tested on a clean machine, deployment notes (where it runs, how it restarts, where logs go), every secret listed in an example env file with a one-line explanation each, KNOWN LIMITS stated plainly (in the scraper: one site falls back to a delayed price feed when blocked; another cannot report stock status, per the OUT list), and WHAT BREAKS FIRST, with the alert behavior and the cost of the likely fix written down in advance.

This whole structure, spec with acceptance tests in front and tested handover behind, is how our development service runs every project, in four domains where we have working demos: scraping, document search, AI integrations and workflow automation. The complete sample below shows both documents at full length. Copy the format for your next freelance hire either way; the format is the part most projects are missing.