Custom Development Project Brief Workbook

What you’ll take away

1. 01

   Describe the problem before the feature

   Begin with an observable operational difficulty rather than a preferred technology. Identify who experiences it, when it occurs and what a satisfactory outcome would look like. Keep the first scope narrow enough for a business owner to accept.

2. 02

   Build the first page of your project brief

   Complete these six decisions before designing screens. Use fictional examples instead of personal records. The template is a discovery aid: the delivery team still needs to confirm feasibility, dependencies and the appropriate implementation approach before a quote is agreed.

3. 03

   Write acceptance before requesting a quote

   The following fictional extension routes unusual booking exceptions for review. It is an example of requirements writing, not a promised product feature. Replace the scenario with your own workflow and state the expected result for every branch.

4. 04

   Make the scope ready for estimation

   A quote needs more than a list of screens. Review these points with the business owner and technical team. Mark unknowns for discovery and name who can resolve them; unresolved assumptions should remain visible in the scope and estimate.

5. 05

   Move from a brief to a scoped extension

   Use the completed brief to discuss a bounded extension within the platform, connected to its records and workflows. The next step should reduce uncertainty: confirm the approach, agree acceptance evidence and obtain a quote that reflects the actual scope.

Agency owners, operations leaders and technical teams preparing a custom extension request. English and French editions are available.