Ten questions that survive a sales call

The call is set up to sound like agreement. You describe the business. They describe a process with the same three words every other studio uses. The useful questions are the ones that produce a noun: a repo, a report, a name on an account.

Ask who writes the code, and whether that person will be on the kickoff. Ask which repository host, and whose organisation the repo is created in. Ask which registrar holds the domain, and whose name is on the registrant contact before the first invoice. Ask what the production deploy command is, and who can run it if they are on holiday. A zip file is not an answer to any of these. The longer note on that failure is the handoff guide.

Ask what ‘accessible’ means in the statement of work. If the answer is a badge, ask for the WCAG version, the level, the pages in scope, and the date. W3C’s evaluation methodology, WCAG-EM, is the shape of a real audit: a scope, a sample, a record of what was tested with a keyboard and a screen reader, not a plugin score. An automated scan misses most failures. Say so in the proposal if that is all they ran.

Ask what they will not install. A theme, a page builder, a chat widget, a pixel that fires before consent. Ask how a sentence gets changed after launch, and whether that needs them. Ask what happens in month thirteen, when the included support year ends. Ask for the field Core Web Vitals report, not a Lighthouse screenshot from their machine.

We would rather lose the call than invent a case study. The two projects on this site are concepts. If a studio cannot tell you which of their screenshots are client work and which are not, that is the answer.