Writing an FDE Project Brief: The One-Page Contract

The short answer

The brief is your cheapest insurance. One page, seven sections, customer-confirmed. If you can't fit it on a page, you don't understand the problem yet.

Template

PROJECT BRIEF - [name] v[n] - [date]
Customer owner: [name, role]    FE owner: [name]

1. PROBLEM
   [2-3 sentences, with one number: volume, cost, or hours]

2. SUCCESS METRICS (90 days)
   - [metric]: from [baseline] to [target], measured by [source]

3. IN SCOPE
   - [deliverable 1..n]

4. OUT OF SCOPE (equally important)
   - [explicit exclusions]

5. CONSTRAINTS
   - [security/data/change-window/licence limits]

6. RISKS & ASSUMPTIONS
   - [top 3, each with a mitigation or owner]

7. SIGN-OFF
   Customer: [name/date]   Delivery: [name/date]

Filled example (condensed)

Problem: Support team spends ~15 h/week manually matching refund requests to payment records across Stripe exports and the orders DB. Success: Manual matching time < 3 h/week by day 60, measured by agent time-tracking tags. In scope: nightly reconciliation service + quarantine report + agent UI for exceptions. Out of scope: refunds processing itself; historical data older than 18 months; mobile UI. Constraints: PII stays in EU region; read-only Stripe key; deploys Tue/Thu 10-12 CET. Risks: Stripe API rate limits at month-end close - mitigation: incremental pulls.

When the customer won't sign

Usually means one of: (a) they don't agree on metrics - resolve in a workshop, not email; (b) politically they can't commit - note assumptions in the brief, proceed with named risk owner; (c) the org doesn't operate on contracts - get email confirmation of the metrics section at minimum. Never start builds against vibes; the scope-change guide explains what unsigned briefs cost you at week six.

Continue: Discovery questions · Scope changes