How Do You Actually Accept a Project? The Pre-Launch Checklist

Acceptance is the most delicate moment in any project: the vendor wants the final payment, you want proof the thing actually works. Too many acceptances go like this — "open the site, click around, looks fine, sign here" — and then every problem surfaces in the first week after launch, with both sides arguing over whether it's warranty work or a new requirement. This article gives you an acceptance checklist you can actually run, and explains what "acceptance" should really involve.

The first principle: follow a checklist, not a feeling

"Looks fine" isn't acceptance — it's a lottery ticket. A good acceptance checklist should exist at contract signing: ideally, every feature in the spec maps to a checkable acceptance item. If your contract has no acceptance checklist, writing one now is still cheaper than arguing on acceptance day.

Functional acceptance: walk the full path, don't just open every page

• Run complete flows with real scenarios: from landing on the site, browsing, ordering, and paying through to receiving the confirmation email — end to end. For e-commerce, run a real NT$1 order through the live payment gateway, not just a green light in the test environment. Our iron rule: "the first real order should not be a debugging session."
• Test the failure paths: declined cards, garbage form input, double submissions, retrying after a network drop. A system's quality hides in its error handling.
• Test the admin panel: have the colleague who will actually use it (not the boss) run a day's work through the back office: edit an order, add a product, pull a report.

Non-functional acceptance: the invisible parts that bite

• Real mobile devices: test on an actual iPhone and an actual Android phone, not a shrunken browser window.
• Performance: run the homepage and key pages through PageSpeed Insights and agree on a baseline score.
• SEO basics: every page has a title and description, URLs are clean, a sitemap exists, GA4 and Search Console are installed.
• Links: crawl the whole site for dead links once. Our internal rule is that no link is allowed to 404, because a single 404 destroys trust in the entire site.
• Security basics: HTTPS everywhere, brute-force protection on the admin login, validation on forms.

Deliverables acceptance: the part everyone forgets

• Source code and deployment documentation (or at minimum, clarity on where it lives and who has access)
• Ownership and admin rights for every account: domain, hosting, payment gateway, e-invoicing, and the rest
• Admin-panel documentation (video is fine — it just has to exist)
• Warranty scope and a support contact

Pay the final invoice without these in hand, and you'll learn exactly how much it hurts the day you want to switch vendors.

Acceptance isn't nitpicking — it's both sides confirming, one last time against the same checklist: what we built is what we agreed to.

One aside: if the vendor has run their own end-to-end tests before acceptance and hands you the test records, that's a mark of professionalism. We explain why we treat this as a discipline in "dumping it on the client to test" is an engineering failure. If you have a project heading into acceptance and aren't sure how to build the checklist, book a free 30-minute consultation — we'll help you fill it in, even if the project isn't ours.