05 / Project preparation

A useful brief starts
with one real task.

You do not need a complete technical specification to start a discussion. A clear example of the work, its constraints, and the intended users is more useful than a long feature wishlist.

Describe the task as it happens today

Choose a request or record that moves through several people. Explain where it begins, what each person adds, and what counts as completion. Note the moment that causes delay or uncertainty. Redacted screenshots or invented sample records can help explain the problem without exposing customer information.

List the tools and boundaries

Name the applications already used and the information that should remain in them. Mention any known export options, access restrictions, internal policies, or required review dates. Identify a person who can explain the business rules and someone responsible for deciding which requirements matter most.

Separate essentials from later ideas

For a first version, describe the smallest complete task the software should support. Put optional reports, extra user groups, and less common integrations in a separate list. This helps compare a limited custom build with configuring an existing application. It also makes a prototype easier to evaluate.

Use the first inquiry appropriately

Send a short summary of the problem and the outcome you want to discuss. Do not email passwords, unrestricted customer records, or access tokens. Any necessary data exchange, confidentiality terms, or system access can be arranged after the scope is understood. A first email opens a conversation; it does not create a development agreement.

Your preparation notes

Five points to consider

Use this optional checklist as a reading aid. Nothing is sent or saved.

0 of 5 points considered.