Prepare a Software or Website Project Brief

A short brief is enough to start

A useful project brief describes the outcome and the current difficulty. It does not require a technical architecture or a long feature list. Write in the language of the person doing the work, and include a public example when it helps.

Seven details to bring

• Outcome: what should become easier, safer or more reliable?
• Users: who starts the task, who reviews it and who should not have access?
• Current process: where does the work happen today and where does it get stuck?
• Inputs and records: what information is required, where is it authoritative and what must stay private?
• Dependencies: which existing applications, providers, URLs or integrations must continue working?
• Acceptance: give one normal example, one denied action and one failure or recovery case.
• Constraints: identify timing, budget range if known, hosting requirements, content to preserve and who will maintain the result.

Illustrative acceptance example

For a service website: “A visitor can find the right service on a phone, read its limits and open the contact form. Missing required fields produce a clear message. A successful submission shows confirmation. The existing insurance and download links still work.” This is a planning example, not a claim that a particular customer approved those requirements.

Separate the first release from later work

Mark the smallest end-to-end result that would be useful. Keep later enhancements in a separate list so the first release can be reviewed without an expanding definition of done. Discuss migration, rollback, documentation and support along with implementation.

Avoid sending passwords, health records, employee records or production exports in the initial inquiry. Describe the data category and access constraints first; agree a suitable exchange process if real records are later necessary.

Custom software development · Web development · Start with your brief