How to commission a business website: brief, stages, and handover

A useful brief starts with the reason for the project, not a screen count. Explain what currently blocks sales, service, or team operations, who uses the site, and which next action matters.

If the solution is not known yet, say so. The studio should turn the problem into a testable scope instead of pricing an unexamined wish list.

The current site, analytics, customer questions, presentations, brand assets, integration list, and liked or disliked references reduce guesswork. They are useful inputs, not a substitute for discovery.

List constraints separately: deadline, mandatory systems, access rules, legal review, and the people responsible for decisions.

Compare proposals by stage outcomes: what exists after discovery, prototype, design, development, and launch. Confirm ownership of content, migration, analytics, integrations, and support.

A short estimate can omit critical work, while a large one can include features the first release does not need. Ask for clear scope boundaries and a change process.

Agree on the primary journeys before development: find a service, assess evidence, submit an inquiry, and receive confirmation. Journey-based acceptance is more reliable than reviewing isolated screens.

Before launch, verify responsive layouts, forms and notifications, analytics, metadata, sitemap, robots, a backup, and a documented rollback path.