How to Review and Accept Work From a Developer — A Practical Checklist

Why Proper Acceptance Matters

Accepting a project without testing it properly is like signing for a delivery without opening the box. Everything looks fine until you find out the item inside was broken.

In the Ukrainian freelance market, many disputes happen not because developers are dishonest, but because both sides had different ideas of what "done" means. A proper acceptance process eliminates most of these disputes.

Before You Even Start the Project

Define acceptance criteria upfront. Literally write in the agreement: "The work will be considered complete when X, Y, and Z are working as described."

Vague: "Fix the checkout." Clear: "Users can complete a purchase with Nova Poshta delivery selected, paying via Liqpay, without errors — tested on desktop Chrome and mobile Safari."

The more specific your acceptance criteria, the easier the review.

The Acceptance Checklist

Core functionality

• Does the main thing you paid for actually work?
• Test it yourself, step by step, as a real user would
• Test on both desktop and mobile
• Test in Chrome AND one other browser (Firefox or Safari)

Edge cases

• What happens if a user makes a mistake? (wrong email format, empty fields)
• What happens on slow internet?
• What if someone tries to order 0 items, or 9999 items?

Performance

• Does the page load in under 3 seconds on mobile? (Test at PageSpeed Insights)
• Check on your phone on mobile data, not Wi-Fi

Access and credentials

• Did you receive all passwords and access credentials?
• Admin panel, hosting, FTP, database — all in your hands?
• Did the developer remove their own access if requested?

Documentation

• Do you know how to do basic tasks yourself? (add a product, change a price, add a page)
• Do you know who to call if something breaks?

How to Give Feedback Without Starting a War

Avoid: "This doesn't work" or "This is all wrong."

Use: "When I click [button] on mobile Chrome, I see [specific error]. Expected behavior: [what should happen]."

Specific bug reports get fixed. Vague complaints create arguments.

Create a shared Google Doc or Notion page. List issues with:

1. What you did (steps to reproduce)
2. What happened
3. What you expected

Number each issue. When it's fixed, mark it done. This keeps both sides sane.

What's Included in the Fix Period

Agree upfront on a warranty period. Standard practice:

• 2–4 weeks of free bug fixes for things that were supposed to work but don't
• Not included: new features you thought of after delivery, changes to what was agreed

Example: if you paid for a checkout fix and the checkout doesn't work — that's a bug, fix is free. If you now want to add a loyalty points system — that's a new project.

The distinction matters. A lot of developer-client disputes happen because the client thinks something is a "bug" and the developer thinks it's "out of scope." Define this before you start.

The Final Sign-Off

When everything on your checklist is working:

1. Send written confirmation: "I confirm the project is complete and accepted."
2. Release final payment.
3. Get all credentials documented.
4. Ask the developer to be available for questions for 2 weeks.

That's it. Clean handover, no disputes, no ambiguity.

The Shortcut Version

If you don't want to go through all of this, at minimum do:

• Test the main feature yourself on your phone
• Make sure you have the admin password and hosting access
• Ask "what do I do if something breaks in a month?"

You can't fully protect yourself without proper testing, but those three things will save you from 80% of common problems.