Process

How to accept work from a contractor

Acceptance isn't looking at the site on a manager's screen. What to check yourself, which access and materials to collect and what to ask before signing off.

Acceptance is the moment after which fixing anything becomes more expensive and slower. Before sign-off you have leverage and the contractor's attention; after it you become one of the clients in the queue. So spending a day or two on acceptance is better than living with unfinished work for months afterwards.

Why "we looked at it together on screen" isn't acceptance

A demo is set up so that everything works. The presenter follows a familiar route, enters correct data, clicks in a predictable order, uses their own browser on their own internet connection. Problems don't live on that route.

You need to accept the work yourself: from your own device, with your own phone, your own connection, your own data. And not by "browsing around" but by scenarios — the very ones the site was built for. If scenarios aren't written down anywhere, start by writing them out: without a criterion, acceptance turns into a list of taste-based remarks.

It helps to involve someone who didn't run the project. A person who has looked at mock-ups for three months no longer sees the site through a new visitor's eyes.

What to check

Complete scenarios

Go through every path to the end and look at the result in the system where it should appear. A request was sent — did the email arrive? To which address? In what form, is the content readable, can you see which page the request came from? An order was placed — did it appear in the CRM, the inventory system, the mailbox?

Check not only the happy path. Submit a form with empty fields, an invalid email, very long text, twice in a row. The site should explain what's wrong, not stay silent or send duplicates.

The mobile version

Checked on a real phone, not by shrinking the browser window. Look for: anything running off the edge of the screen, whether buttons are easy to tap, whether a sticky header covers content, whether the form is easy to fill in, whether the right keyboard opens for phone and email fields.

Separately — an older phone with a smaller screen. That's usually where your visitor actually is, not on the latest model.

Forms and feedback

For every form on the site you need to know four things: where the data goes, who gets the notification, what the sender sees after submitting, what happens on failure. There's no such thing as a "just in case" form: if there's no recipient, the form silently loses requests, and you won't find out for a long time.

Check spam protection too. A completely unprotected form starts bringing in junk some time after launch, and real requests get lost in it.

Speed

Open the site on mobile data, not the office Wi-Fi. Look at the heavy pages: the catalogue, the gallery, the home page. Slow loading isn't just an inconvenience but bounces and lost search rankings. If there are no measurements at all, set them up before launch — it's part of working with analytics.

Content

Simple things that are skipped most often: phone numbers and addresses are real; links in the menu and footer go where they should; there's no leftover placeholder text or stubs; tab titles aren't the same on every page; the favicon is in place; a 404 page exists and offers somewhere to go; the privacy policy is in place if you collect contact details.

The technical minimum

Check that the site opens over HTTPS and that the non-secure address redirects to it. Make sure one primary address is chosen — with or without www — and the other points to it. See whether analytics is connected and whether form submission events arrive in it. Confirm the site is open to indexing: a block left over from development is the classic reason a site doesn't appear in search for months.

What to collect besides the website

A working website isn't the only result of the work. Before signing, get hold of:

  1. The domain — the registrar, the account, control over renewal. The domain should be registered to you, not the contractor.
  2. Hosting or the server — access, where everything is, who pays and when the next charge is.
  3. The admin panel — an account with full rights for you personally, not a shared login for everyone.
  4. Source code — a repository or an archive, depending on how rights are set out in the contract.
  5. Design source files — editable mock-ups, fonts and their licences, images.
  6. Email settings — which service sends emails from the site, and where that account is.
  7. Analytics and webmaster tools — on your account, with admin rights.
  8. A short guide — how to add a page, a product, a news item, change text and an image.
  9. Backups — where they're stored, how often they're made, how they're restored.

The access test is simple: could you hand the project to another contractor tomorrow without a single call to the previous one? If not, you've received not a website but a subscription.

Questions before signing

These things are discussed before sign-off, because afterwards your position changes.

  • What counts as a bug and what as a new task, and who decides disputed cases.
  • How and through which channel to report bugs — email, a tracker, chat.
  • What happens with bugs found after acceptance, and on what terms.
  • Who is responsible for the site working: who'll notice it's down, and who'll bring it back up.
  • How ongoing support works: what's included, what's paid for separately.
  • Who updates the platform and components, and how that's arranged.
  • What happens if an urgent fix is needed out of hours.
  • What the contract says about rights: can the code be handed to another contractor?

Get the answers in writing. Not because the contractor will deceive you, but because people in companies change while correspondence remains.

Acceptance checklist

  1. Go through all main scenarios yourself and check the result at the other end.
  2. Open the site on your phone and on an older phone.
  3. Submit every form — correctly and incorrectly — and make sure the emails arrive.
  4. Check speed on mobile data.
  5. Scan the content: contacts, links, placeholders, tab titles, 404.
  6. Confirm HTTPS, one primary address and open indexing.
  7. Get all access on your own accounts and check that login works.
  8. Collect source files, mock-ups and the guide.
  9. Record the terms for bugs, support and urgent fixes in writing.
  10. Only then sign.

If any point causes difficulty or you need an outside look at finished work — write to us, and we'll go through it in substance.