The stage where outsourced projects most often capsize isn't development — it's acceptance. However well you scoped it and however hard the work was, without clear acceptance criteria it usually ends one of two ways: the client feels "this isn't what I pictured" and refuses the final payment, or the vendor feels "you keep changing the spec" and won't fix more. From an agency's perspective, here's a UAT (user acceptance testing) checklist an SMB can follow, and how to tie payment milestones to acceptance so both sides feel safe.
Why Acceptance Is the Fight
Because most disputes trace back to never defining "done" clearly. If the requirements are vague, everyone's mental bar differs at acceptance. The fix isn't to argue at acceptance — it's to front-load the criteria: before development, write which scenarios must run and what result counts as a pass into the requirements doc, so acceptance is just ticking boxes.
UAT Checklist: Five Dimensions
- ☐ Function: Real user scenarios pass end to end (sign-up, order, pay, email, admin actions) and match the spec.
- ☐ Performance: Key pages load within target; ask the vendor for Core Web Vitals (LCP etc.) results.
- ☐ Compatibility: Works on major browsers and mobile/desktop; cross-check MDN browser compatibility data.
- ☐ Security: Covers at least OWASP Top 10 risks; sensitive data encrypted, admin has access control.
- ☐ Deliverables: Source code, credentials, deployment docs and admin guide all handed over (don't get locked in).
Tying Payment Milestones to Acceptance Fairly
| Milestone | Deliverable | Acceptance criteria | Suggested payment |
|---|---|---|---|
| Signing | Requirements doc, timeline, scope | Both sides confirm scope and spec | Deposit 20–30% |
| Mid-development | Core features demoable | Main flows run end to end | 20–30% |
| Acceptance | Full system + test environment | UAT checklist passes and is signed | 30–40% |
| Go-live + warranty | Live launch, all deliverables handed over | Through warranty with no major issues | Retain 10–20% |
Common Disputes × Prevention
| Dispute | Prevention |
|---|---|
| "This isn't what I pictured" | Attach mockups/prototype to the spec; front-load acceptance criteria |
| "Is this a bug or a new requirement?" | Define in the contract: off-spec = fix free, new = change billing |
| Acceptance drags, final payment stalls | Set a clear UAT deadline and a 'deemed accepted' clause |
| Deliverables incomplete, you're locked in | Make source code and credentials a condition of acceptance and final payment |
Acceptance SOP (Follow Along)
The right order: get a working test environment and test accounts → test by real user scenarios, recording expected vs actual → sort issues into "off-spec" and "new requirement" → re-verify and sign off each fixed item → release the milestone payment on passing, then schedule go-live. Throughout, never accept on live data — once real data is in, many issues are hard to reverse.
FAQ
I'm not technical — how do I accept an outsourced website or app?
You don't read code; you accept by user scenario. Walk through the real actions that will happen (order, pay, receive email, edit data in the admin) and check the results are right. For performance, security and compatibility, ask the vendor for test reports or a live demo — your job is to confirm 'was it done and does it meet the bar,' not to test it yourself.
How long should acceptance take? Can I test while going live?
Keep an explicit UAT (user acceptance testing) window — usually a few days to two weeks depending on size. Don't 'test while live': once real data is in, many issues become hard to reverse. Accept and sign off in a test environment first, then schedule the go-live.
How do I tie payment milestones to acceptance so I'm neither stiffed nor stuck?
Use milestone payments where each node maps to clear deliverables and acceptance criteria, paid only on passing. A common structure: deposit on signing, a mid-development payment, a payment on acceptance, and a retained final sum tied to the end of the warranty. Both sides feel safe: you don't pay all up front, the vendor isn't working for free.
Acceptance found lots of issues — is the vendor bad, or am I asking too much?
Classify first. Split into 'doesn't match the agreed spec (bug/gap)' and 'new requirement I thought of later (change).' The vendor should fix the former free; the latter is scope change and is billed. Draw that line in the contract and requirements doc up front, and acceptance won't become a he-said-she-said fight.
Call to Action
Taking over acceptance of an outsourced website or app and not sure where to start? We'll map an acceptance checklist and payment milestones to your project and run an independent technical acceptance. Free consult:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p