Hiring a website or web app team: what to prepare and accept

Describe the current situation, who is affected and what should change. “Modern” may be a useful visual preference, but it is not enough to establish whether the work functions correctly.

An illustrative brief might say: “Website enquiries currently arrive in a shared inbox. The team cannot see who owns each request. We need a status, an assigned owner and a searchable history for every enquiry.” This supports a discussion about intake, record storage and assignment.

Identify what is outside the first scope too. Automatic pricing and accounting integration might be excluded. Clear boundaries make options easier to assess and allow later additions to be discussed with their actual impact.

Describe user groups by their work: visitors submitting information, staff receiving enquiries, managers reviewing progress and editors maintaining content. Explain what each group may view or change. Detailed technical permission terminology can come later.

Identify who approves scope, who checks content and who accepts the working experience. When everyone can comment but nobody can decide, a project can cycle through revisions even if the developer follows every suggestion.

For two languages, establish who owns each edition, which content must have an equivalent version and what happens when one translation is not ready.

For the enquiry example, the journey might be: a visitor enters information, required fields are checked, the request is stored, the receiving team is notified and the visitor sees confirmation. An employee then takes ownership and updates its status as contact progresses.

Include important branches: incomplete information, duplicate submission, an unsupported attachment, delayed notifications or an absent owner. Describing only successful journeys understates the work required for everyday use.

Provide representative, appropriately redacted records and examples of current documents or screens. Realistic field lengths, file types and exceptions help a developer understand the task more effectively than an abstract feature list.

Missing dependencies can leave a finished interface unusable. List the owner and readiness of the domain, hosting, service accounts, email delivery, existing data, images and publication content.

For connected systems, identify the administrator, available connection documentation and known constraints. Credentials do not belong in the brief. Agree appropriate access arrangements when they are needed.

For images and copy, establish usage rights and who edits and approves them. If the design contains placeholder text, treat preparation of the real content as a distinct responsibility. A complete set of pages does not establish publication readiness.

“Easy to use and free of bugs” expresses an intention but is difficult to test. Write a situation, the action taken and the expected result. For the enquiry example:

1. A complete submission creates one request and shows confirmation consistent with the actual next step.

2. Missing required information is identified without clearing valid information already entered.

3. Accounts with different roles can view and edit only the permitted information.

4. A failed notification leaves the saved request visible and recoverable without silently creating another record.

5. Both languages remain understandable on a narrow screen, including labels, errors and submission steps.

Use representative data and involve each user group in testing. Give findings an owner and a decision: must they be resolved before launch, or are they additional work for later? A collection of unresolved chat comments is not an acceptance record.

Discuss the operating accounts, backups, data export, user guidance and issue-reporting route before work begins. Clarify the agreed maintenance scope and associated costs. Deliverables absent from a proposal should not simply be assumed to be included.

Testing on a developer's machine and operating on the real domain are separate checkpoints. Assign responsibility for checking configuration, access, integrations and receipt of enquiries after launch. Establish how to recover if a critical step fails.

With the brief completed, the developer should be able to explain the deliverables, whose input is still needed and what evidence will support acceptance. Resolve gaps in those answers before spending time on screen details that do not affect the main work. The purpose of the brief is to help both sides recognise the same project from the beginning.

If you are unsure whether a full custom build is needed, compare packaged software, integration and custom development before fixing the scope, so the brief reflects a suitable approach.