Acceptance is the most underrated stage of a project. Formally it looks like "have a look and say okay." In practice it decides whether you end up with a working result or a pile of files that cannot be changed a month from now.
The two most common client mistakes are mirror images: accepting on impression ("looks nice, let's pay") and accepting endlessly (ten waves of revisions with no completion criterion). The first produces problems a month later; the second wrecks the relationship and blows the deadline.
Proper acceptance is a procedure with a fixed sequence: verification against what was agreed, technical checks, handover of assets, one structured revision list, final payment. Below is exactly that procedure, plus checklists for the main types of work.
The Main Rule: Accept Against the Spec, Not the Mood
If scope and acceptance criteria exist in writing, acceptance takes an hour and produces no conflict. If they do not, every conversation becomes "it feels wrong to me" versus "you never asked for that."
So the check starts not by opening files but by opening the document: take the list of what was supposed to be built and walk through it. If no such list exists, write one now, before paying. What it should contain is covered in How to write a brief.
Changes outside what was agreed are not "a small thing" — they are new work. That is fine and can be ordered, but it is a separate agreement, not part of acceptance.
The Acceptance Sequence: Five Steps
- Verify against the list. Walk the scope items: is everything there? Did anything quietly disappear?
- Functional check. Does what should work actually work: forms, buttons, payments, search, links.
- Technical check. Mobile, browsers, speed, console errors, correct files and formats.
- Content and details. Spelling, current contacts, correct prices, captions, metadata.
- Handover of assets. Access, source files, rights, documentation. Before payment, not after.
Step five is skipped most often and costs the most later. Getting source files out of someone who has already been paid and moved on to the next project can be impossible.
Checklist: Website
Functionality
- Every form submits and the email or lead actually arrives (test it yourself, do not accept "it should work").
- Field validation works: what the user sees on error, whether an empty form can be submitted.
- Search, filters, cart and checkout work end to end, with a test payment.
- No broken links; a 404 page exists and leads back into the site.
Mobile and browsers
- Check on a real phone, not just by narrowing the window.
- Nothing overflows the screen; there is no horizontal scroll.
- Buttons and fields are comfortable to tap, text is readable without zooming.
- Check at least two browsers.
Technical
- Load speed is acceptable on mobile data; images are compressed.
- HTTPS works with no certificate warnings.
- Page titles and descriptions are filled in (not "Home" on every page).
- Favicon is in place; link previews render in messengers.
- Analytics is installed and recording visits.
- The site is open to indexing (a classic mistake is a leftover blocking robots file from development).
Content
- Spelling and punctuation; contacts, prices and legal details are current.
- Images are not stretched and carry no third-party watermarks.
- Legal pages are present where required.
Access
- The domain is registered to you, not to the specialist.
- You hold access to hosting, admin, repository, analytics and email.
- You can change a text and add a page yourself (verify it, do not assume it).
What generally belongs in a website's price and what is billed separately is covered in How much does a website cost.
Checklist: Design
- Source files, not just images. A working layered file, not only PNG or PDF.
- File structure. Named layers, components and styles — otherwise the next designer spends days deciphering it.
- All element states: hover, pressed, error, empty, loading.
- Responsive layouts. Mobile mockups, not desktop only.
- Fonts and licenses. Which fonts are used and whether commercial rights exist.
- Imagery. Sources of photos and icons plus usage rights. An unlicensed stock image becomes your problem, not the designer's.
- Export for development: icons and images in the required formats and sizes.
- Brand compliance, if a brand guide exists.
Checklist: Video
- Formats and dimensions match the destination: vertical for stories and reels, horizontal for YouTube.
- Loudness is consistent, with no clipping or jumps between scenes.
- Captions exist where needed and are in sync; names, brands and numbers are spelled correctly.
- Titles and graphics are free of typos and not cropped on different screens.
- Music is licensed, with proof of rights.
- Watch it on a phone, with and without sound — that is how the audience will see it.
- Source materials: the edit project and raw files, if the agreement covers them.
What to demand from video work and what to look for in an editor's portfolio is covered in Video editor portfolio.
Checklist: Copy
- Fits the task: the text does what it was meant to do (explain, sell, inform).
- Factual accuracy: figures, names, terms and links — verified by you, because the responsibility is yours.
- Tone and audience match the brief.
- Structure: headings, paragraphs, lists — the text survives scanning.
- Originality checked, if that matters for publication.
- Delivery format: how you received it and whether it is convenient to publish.
How to Give Revisions
The expensive part of acceptance is not the revisions themselves but how they are delivered.
- One list, not a stream of messages. Ten messages across a day cost more of the specialist's time than one structured list.
- Specific and addressed. Not "I don't like the header" but "the logo in the header is too big, roughly halve it."
- Prioritized. Separate "blocks launch" from "would be nice someday."
- One wave, one list. Adding new items while previous ones are being fixed is the main cause of blown deadlines.
- Separate defects from new wishes. A mismatch with the spec is fixed within scope; a new wish is a new task with its own estimate.
- Fast. Feedback two weeks late costs more than any revision: the specialist has lost context.
What if the result does not match what was agreed?
Handle it calmly and in writing. Produce a list of discrepancies referencing specific spec items: "item 4 — the form was to have three fields, it currently has two." That is not conflict, it is fact-checking, and in most cases it resolves without drama.
If the discrepancies are systemic (something fundamentally different was built), discuss one of the options: rework within the paid scope, partial payment for what was genuinely delivered, or ending the engagement with handover of what exists. The worst scenario is accepting silently, paying, then demanding free rework: legally and practically that is a weak position.
The main insurance against this is stage-by-stage acceptance rather than one big delivery at the end.
When to Pay
- A deposit up front is normal: the specialist reserves time.
- Stage payments are the healthiest arrangement for medium and large projects: each side risks one stage.
- The final payment comes after handover of assets, not after the words "it's all done." That is standard practice, not distrust.
- Do not drag out the final payment after acceptance. Late payment is the fastest way to lose a specialist you will want to work with again.
Common Acceptance Mistakes
- Accepting on impression. "Looks nice" is not a criterion; the list of what was to be built is.
- Not checking on a phone. That is where most of the audience is.
- Not collecting access and source files. The most expensive mistake of all.
- A domain registered to the specialist. A year later that can become a hard negotiation.
- Endless waves of revisions. With no completion criterion, the project never ends.
- Mixing defects with new wishes. It damages the relationship and breaks the scope agreement.
- Going silent for two weeks, then demanding urgency. That is exactly how deadlines die.
- Not recording acceptance in writing. One message — "work accepted per items 1–7" — closes the question for both sides.
Key Takeaways
- Accept against written scope and criteria, not impressions.
- The sequence: verify the list → functional check → technical check → content → handover of assets.
- Collect access, source files and rights before the final payment.
- The domain and accounts must be registered to the client.
- Test websites on a real phone and forms with a real submission.
- Deliver revisions as one structured, prioritized list.
- New wishes are new tasks, not part of acceptance.
- Record acceptance in writing and do not delay the final payment.
FAQ
What should I check before paying for work?
First verify the result against the list of what was supposed to be delivered, then test it functionally (forms, buttons, payments), technically (mobile, browsers, speed), then content and details. The last and most important step is collecting access, source files and rights before the final payment. After payment, obtaining assets becomes much harder.
How many revisions can I ask for after delivery?
As many as the agreement specifies — typically one or two waves are included in the price. The important distinction: a mismatch with the spec is fixed within scope at no extra cost, while a new wish that was never in the spec is a new task with its own estimate. If the number of rounds was never agreed, settle it before acceptance begins.
Which access credentials must I collect?
The domain (registered to you), hosting, site admin, code repository, analytics and email accounts, plus source files for design or video. Separately, verify usage rights for fonts, images and music. The best moment to ask is before the final payment, while the project is still active.
What if the work does not match the spec?
Write a list of discrepancies referencing specific agreed items — that is fact-checking, not conflict. Then discuss rework within the paid scope or partial payment for what was genuinely delivered. The best insurance is accepting the project in stages rather than as one large delivery at the end.
What to Do Next
Before acceptance, build your own checklist from the lists above, tailored to the type of work. Fifteen minutes that replace several days of messaging.
Run acceptance through the five steps, send one structured revision list, record acceptance in writing after the fixes, and close the payment. And if the engagement went well, leave a review: it costs you five minutes and gives the specialist their strongest social proof. Find specialists in the talent catalog, and for the next project see How to choose a freelancer.
Ready to act?
- Find a specialist in the catalog: https://searchtalent.dev/en/talents
- Browse specialists' projects: https://searchtalent.dev/en/projects
- Skills and technologies catalog: https://searchtalent.dev/en/talents/skill
- More articles: https://searchtalent.dev/en/articles
