Prostor
All articles
22 October 2026

Accepting a website: what to check before you sign off

Ruslan Kochubarov
Ruslan Kochubarov · Founder and art director

A staged handover checklist — what to review in wireframes, in design, and on the live site, plus what to collect while you still have leverage.

Acceptance is not the same as liking it

Sign-off is not a taste decision. A layout can be attractive and still unusable: it may have no answer for a long product name, an empty catalogue, or where the button goes on a narrow screen. Those things do not surface in a presentation. They surface a month into operation.

It helps to split acceptance into three moments that follow the project stages. Each checks something different, and whatever is skipped early costs more later.

Accepting the structure

The cheapest stage to change and the one most often waved through. What matters is not beauty but sequence: the path a visitor takes, the order in which they get the argument, and where they can reach you.

Useful questions: what does someone see first, and is it enough to know where they have landed; how many steps to an enquiry; are there pages nothing links to. Check the last one literally — a section with no path from the menu or the body copy is largely invisible to search engines too.

Accepting the design

Here you review states, not pictures. Every screen has more than one and usually only the happy one is drawn.

  • What the page shows with no data: empty catalogue, no reviews, no photograph.
  • How the longest product or service name behaves.
  • What the form does on error, and what the visitor sees after submitting.
  • How each block behaves on a narrow screen — not "is there a mobile version" but what happens to this block specifically.

If those have no layouts, the developer will invent them, and you will see the result already built.

Accepting the live site

Check on the real URL, on your own phone, in the browser you actually use. The minimum round:

Substance. Prices, service names, company details, phone numbers, people. This is the one thing a contractor cannot verify — they do not know which price is right.

Enquiries. Send a test enquiry and confirm it reaches someone who reads it. Try every channel: form, messenger, phone. While you are there, check the goal fired in analytics — what should be in place is covered in analytics before launch.

Speed. Open the homepage on mobile data, not office wifi. The gap between those two checks is usually the gap that costs you visitors.

Small copy. The browser tab title, button labels, the footer line, the 404 page. These never appear in a design presentation and therefore reach production in draft form.

Collect it while you have leverage

The payment moment is the easy time to get everything. Collect the design sources, repository access, and credentials for the domain, hosting and every connected service, plus a short guide for updating content. If any of that stays with the agency, you are tied to them by default rather than by choice.

Agree the warranty window in the same conversation, including where the line falls between a defect and a new request. That line is almost always contested, and it is calmer to draw it before payment than in the moment something breaks. Choosing a contractor in the first place is covered in redesign or rebuild.

Questions

What should be handed over with a finished site?

Editable design source files, access to the code repository, credentials for the domain, hosting and every connected service, and a short guide to updating content. Anything that stays with the agency is a dependency you did not choose.

Can a site be accepted from screenshots?

No. A screenshot shows one width in one browser and no behaviour: how the menu opens, what happens on a slow connection, whether an enquiry arrives. Acceptance happens on the live URL and on your own phone.

Who pays if something breaks a month later?

Agree it before you pay. The usual arrangement is a warranty window in which fixing defects in delivered work is included, while new requests are quoted separately. The part worth writing down is what counts as a defect and what counts as a new request.

Should the client test the site at all?

Yes, but not as a QA engineer. Your job is the part only you can verify: correct prices, correct company details, the right service names, and that enquiries land where someone reads them. The contractor checks the technical side; you check the substance.

First page of the Prostor project brief template
Resource

Project brief template

The same document we send clients before we start. Seven sections, about twenty minutes to fill in, and it removes half the questions from the first call.

What is inside
  • Company and project
  • The task and what success looks like
  • Who buys
  • What the site needs
  • Timeline, budget, constraints
  • Taste and examples
  • Materials and sign-off
PDF · 3 pages · fill it in by hand or in any editor

Tell us the task in four answers

Answer with the buttons or in your own words — that is enough for us to come to the call with thoughts instead of generic questions.

Ruslan Kochubarov
Ruslan Kochubarov
Founder, art director

Tell us about the task

Book a 30-minute call or leave a request — we reply within 30 minutes during working hours and send a brief and relevant examples.

Book a call

Projects from $3,000 · ongoing support from $1,500/mo

  1. Reply within 30 minutes
  2. A 30-minute call
  3. A scoped estimate