Most outsourcing disputes I've seen don't start during development. They start the week after the last invoice is paid, when the client discovers that the server is on the developer's personal account, the email service runs on someone else's API key, and nobody wrote down how to deploy.
We run a small development studio, so we sit on the delivering side of this. Over time we turned "what should be true before the final payment" into a written acceptance checklist that we send to clients before delivery. It protects both sides: the client knows exactly what "done" means, and we get a clear acceptance date instead of an open-ended "one more thing."
Here is the short version. If you freelance, feel free to copy it into your own contracts.
The 10 checks
1. Every feature, one row in a table. Copy the features from the quote or spec into a table and mark each row pass or needs fixing. Clicking around the obvious screens is how missing features slip through.
2. Real devices, real browsers. Run the core flows on what users will actually use: an iPhone with Safari, a mid-range Android phone, Chrome on desktop. "Works on my machine" is not acceptance.
3. The unhappy paths. Submit an empty form, type a wrong password, go offline. A clear message is a pass. A blank page or a raw stack trace is a fix.
4. Accounts in the client's name. Admin panel, server, database, email sending, maps, payments: each should sign in with the client's own email, not a borrowed developer account. Change passwords after handover.
5. Source, repo, domain, server. The full source lives in a repository the client owns. The domain registrant and hosting account are in the client's name. Compare against the contract line by line.
6. Deployment is written down. Install, configure, build, upload, restart. If another developer could ship a new version from that document alone, it's enough. Secrets go over a separate channel, never in the README.
7. Personal data and backups. What is stored where? Are passwords hashed? Does the privacy policy match what the code actually does? Do backups run automatically, and has anyone ever restored one?
8. The bug-fix window is in writing. How many days of free fixes, starting from which date (acceptance or delivery), and what counts as a bug versus a new feature request.
9. Licenses for fonts, images and libraries. A list of every font, photo and icon, whether commercial use is allowed, and whether credit is required. "Found it on Google Images" turns into a legal email later.
10. Basic performance. How fast the first screen appears on mobile data, whether images are oversized, whether text is readable on a phone. If the contract has numbers, test against those.
Tie the final payment to acceptance
This is the part that actually prevents the arguments. Put three things in the contract:
- a review period (for example, 7 days after delivery),
- how fix requests are filed (in writing, against the checklist rows),
- and that the final payment is due a few days after the acceptance date, which is the day every row reads pass.
The filled-in table becomes the acceptance record. No one has to remember what was agreed in a call.
This is general information, not legal advice. Have important contracts reviewed by a professional.
Full version
The longer guide has an example for each check and sample contract wording: Acceptance Checklist: 10 Things to Verify Before the Final Payment. It's on our studio site (HS Solution), so yes, that's our page.
What's on your own handover list that isn't here? I'm especially curious how other freelancers handle third-party API keys.
This post was written by an AI assistant from the checklist we use in our own projects.
Top comments (3)
Sending the checklist before delivery is the part that does the work. A client who has seen the list for two weeks accepts the result in days; a client who first sees it at handover treats it as a new negotiation. The other quiet win is number 8: a written bug fix window with a start date turns the vague post delivery tail into a calendar entry, which is usually the difference between a clean close and six months of "one more thing".
Thanks, that matches what we see. The list works best as a shared doc both sides edit during the build, so nothing on it is new at handover.
On #8, we also write down what counts as a bug versus a change request inside that window. Without that line, the window quietly turns into free feature work.
How do you handle the start date when the client delays their own testing?
We tie the clock to delivery, not to their testing. The checklist says the review window starts the day the build is handed over and runs a fixed number of business days, whether or not they have started testing. Anything reported after it closes is a change request, priced separately.
When their testing does slip, the start date moves by the slip plus the time to rebook the people who were scheduled. We put that line in the same checklist before the build starts, so the delay cost is their visible choice rather than a surprise invoice at the end.