# Acceptance Criteria Examples for Small Software Jobs

> Acceptance criteria are testable statements that define when a job is done. Good ones describe a starting situation, an action and an observable result with concrete values, for example: after submitting the form, the enquiry arrives in the sales inbox within five minutes. For a small software job, three to seven criteria are usually enough.

- URL: https://kleinerauftrag.de/en/scoping/acceptance-criteria-examples/
- Language: en
- Updated: 2026-10-19
- Publisher: Kleiner Auftrag (OnlineBuilders LLC, https://onlinebuilders.biz)

Ask a shop owner and a developer what "the form should work" means, and you'll get two different answers. The owner pictures enquiries landing in the inbox, on every phone, never in spam. The developer pictures a form that submits without an error message. Both are reasonable. Only one of them gets built.

That gap between "works" and "works the way I meant" is behind a lot of the rework that small jobs end up arguing about. Acceptance criteria close it before anyone writes a line of code.

## What makes a criterion testable

An acceptance criterion describes a result someone can check from the outside. It says nothing about how the developer gets there. Three questions help you write one:

- Could a third person check it in a few minutes without reading the code?
- Is there a concrete value where one belongs? Five minutes, three test emails, 2.5 seconds.
- Does it describe what happens rather than what someone should do?

"The page should load fast" fails all three. "The homepage scores a Largest Contentful Paint of 2.5 seconds or less in a mobile Lighthouse test" passes. That 2.5-second figure isn't invented, by the way. Google's documentation on [Largest Contentful Paint](https://web.dev/articles/lcp) uses it as the threshold for a good score.

## Two formats: checklist or Given/When/Then

The simplest form is a list of statements that must be true after delivery. For most small jobs that's all you need.

Flows with several steps benefit from more structure. The Given/When/Then pattern comes from Gherkin, the language behind the Cucumber testing tool:

- **Given** sets the starting point, such as a logged-in customer with an item in the basket.
- **When** describes the action, like tapping "Place order".
- **Then** states the observable outcome: the order confirmation email arrives.

The [Gherkin reference](https://cucumber.io/docs/gherkin/reference/) recommends three to five steps per example. Longer scenarios get hard to read as a specification. Needing ten lines usually means you are describing two cases at once.

If your developer works with user stories, you may see the format "As a [role], I want [feature], so that [benefit]". That sentence explains why the work matters. The acceptance criteria underneath it say when it's finished. You need both, but the criteria are what you check at sign-off.

## Twelve acceptance criteria examples for common small jobs

Adapt these and drop them straight into your [brief for the developer](https://kleinerauftrag.de/en/scoping/how-to-brief-a-developer/). The values are suggestions, not standards.

**Fixing a contact form**

1. Three test messages from three different sender addresses arrive in the sales@ inbox within five minutes.
2. None of the test messages end up in the spam folder at Gmail or Outlook.
3. The form can be submitted on a current iPhone and on an Android phone.

**New field at Shopify or WooCommerce checkout**

4. Given a guest at checkout, when they enter a VAT number in the new field and place the order, then the number appears in the order details in the admin and on the invoice.
5. If the field is left empty, the order still completes.

**Custom WordPress plugin**

6. The plugin runs without PHP errors or warnings on the current WordPress release and the PHP version your host provides.
7. Deactivating it leaves the site working. Deleting it removes the plugin's own database tables.

**Sync between shop and accounting software**

8. Given a paid order, when it is marked as completed in the shop, then a sales invoice with the identical gross amount exists in the accounting software within 15 minutes.
9. If the transfer fails, a named email address receives a message with the order number and the error.

**Page speed**

10. The homepage scores a Largest Contentful Paint of 2.5 seconds or less in a mobile Lighthouse test.

**Bug fix**

11. Following the steps from the original [bug report](https://kleinerauftrag.de/en/scoping/how-to-write-a-bug-report/) no longer produces the error, checked on the device and browser named there.
12. The developer sends a short note listing which files or settings were changed.

The last one looks trivial. It's the one that saves you an hour of searching the next time something breaks.

## Weak vs testable: side by side

Weak criteria tend to fail in the same few ways. They judge instead of describe, leave values open, or ask for something nobody can verify.

**From wish to testable criterion**

| | Weak | Testable |
|---|---|---|
| Form | works reliably | 3 test emails arrive within 5 min, none in spam |
| Speed | loads fast | mobile LCP of 2.5 s or less in Lighthouse |
| Design | looks modern | matches the attached mock-up at 375 and 1440 px width |
| Integration | syncs everything | paid orders appear within 15 min with the same amount |
| Security | is secure | admin login only possible with a second factor |

Design deserves a note. "Matches the mock-up" only works if there is one. An annotated screenshot is enough. Without a reference, taste decides at sign-off, and taste is endless to argue about.

## The forgotten criterion: what must not break

Nearly every example above describes something new that should work. Just as important is what must keep working exactly as before. One plugin update fixes the form and quietly breaks the newsletter sign-up. Often a customer is the first to notice.

So add one criterion that protects the two or three business-critical flows on your site. Something like: "After the change, a test order paid with PayPal and an enquiry through the contact form both complete successfully." That costs the developer ten minutes of testing. Worst case, it saves you a day without orders. To make rolling back possible if it does go wrong, take a fresh [backup of the website](https://kleinerauftrag.de/en/delivery/how-to-back-up-a-website/) before any change.

## How many criteria does a small job need?

Three to seven. Fewer than three usually means edge cases are missing: empty field, wrong input, mobile device. Go past seven and the job probably isn't that small any more and could be split in two.

Every criterion has a price. Any developer who promises that no test email lands in spam has to check the mail setup and may need to adjust SPF and DKIM records in your DNS. Sensible, but it's work. Good criteria sometimes make a quote higher. You get what you need in return, at an honest price. How that plays out between pricing models is covered in our comparison of [fixed price vs hourly](https://kleinerauftrag.de/en/costs/fixed-price-vs-hourly/).

**Quick test for every criterion**

- [ ] Checkable from the outside, without reading the code
- [ ] Contains a concrete value (time, count, amount, width)
- [ ] Describes a result, not a building instruction
- [ ] Names device or browser where it matters
- [ ] Covers at least one edge case (empty, wrong, mobile)

## From criteria to sign-off

Acceptance criteria earn their keep at the end. At sign-off you go through them one by one and tick them off. What passes is done. What fails goes back with a description. That routine maps directly onto a [project sign-off template](https://kleinerauftrag.de/en/delivery/project-sign-off-template/) you confirm by email or signature.

If you commission work regularly, you'll notice the same criteria coming back: backup before release, test on a phone, short note of changes. Write those once as a standing list and attach it to every brief. Teams that [build and run software long term](https://onlinebuilders.biz/solutions/software-development) keep a definition of done for exactly that reason.

For your next job, set aside ten minutes, write three criteria following the pattern above, and ask the developer to review them before sending a quote.

## FAQ

### What's the difference between acceptance criteria and a definition of done?

Acceptance criteria belong to one specific task, such as a contact form. A definition of done applies to every task a team delivers, for example "code is in the repository and a backup was taken before release". For one-off jobs with a freelancer you mostly need acceptance criteria.

### Who should write the acceptance criteria?

You write the first draft, because only you know what you need. The developer adds technical points and tells you when a criterion can't be tested or would be disproportionately expensive. The agreed version goes into the quote or the order confirmation.

### Do I have to use the Given/When/Then format?

No. It helps with flows that have several steps. For simple changes like a text update or one extra field, a plain sentence or a checklist works just as well.

### What happens if a criterion isn't met at delivery?

Then the work wasn't delivered as agreed, and you can ask for it to be fixed before you sign off. That is the whole point: criteria turn a feeling into something both sides can check.

Photo: Marcos Costa Junior, CC BY-SA 4.0 (https://commons.wikimedia.org/wiki/File:Simples-Quadro-Kanban-03.jpg)