Skip to content

Latest commit

 

History

History
123 lines (80 loc) · 3.56 KB

File metadata and controls

123 lines (80 loc) · 3.56 KB

Project Brief

This is the primary source of project intent. It captures why the project exists, who it serves, and what it aims to achieve.

For technical architecture, see docs/architecture.md. For setup and usage, see README.md.

This document is written once during project kickoff and remains largely stable. Major direction changes are recorded in the Revision Log at the bottom.


Project Overview

  • Project name: [PROJECT_NAME]
  • One-line summary: [A single sentence describing what this project does]
  • Problem: [What problem does this project solve? Why does it matter?]
  • Target users: [Who will use this? Be specific — not "everyone"]
  • Value proposition: [Why would target users choose this over alternatives or doing nothing?]

Success Criteria

[How do you know this project succeeded? Be concrete.]

  • [CRITERION_1]
  • [CRITERION_2]
  • [CRITERION_3]

Core Features

[The main capabilities the product must have. Keep it focused — 3 to 7 items.]

  1. [FEATURE_1]
  2. [FEATURE_2]
  3. [FEATURE_3]

Primary User Flows

[The key journeys a user takes through the product. Describe the most important 2-3 flows.]

[FLOW_NAME_1]

  1. [STEP_1]
  2. [STEP_2]
  3. [STEP_3]

[FLOW_NAME_2]

  1. [STEP_1]
  2. [STEP_2]
  3. [STEP_3]

Technical Direction

  • Platform: [web, mobile, desktop, CLI, API, etc.]
  • Stack: [languages, frameworks, databases — if decided]
  • Deployment: [how and where this will run — if decided]
  • Key technical decisions: [any strong preferences or constraints on tech choices]

Roadmap

[High-level phases, not detailed task lists. Each phase should have a clear goal.]

Phase 1: [PHASE_NAME]

  • Goal: [What does "done" look like for this phase?]
  • Scope: [What's included?]

Phase 2: [PHASE_NAME]

  • Goal: [What does "done" look like for this phase?]
  • Scope: [What's included?]

Phase 3: [PHASE_NAME]

  • Goal: [What does "done" look like for this phase?]
  • Scope: [What's included?]

Competitive Landscape

[Who else is solving this problem? What exists today? This sharpens the value proposition and informs technical decisions.]

  • Direct competitors: [Products that solve the same problem for the same users]
  • Indirect alternatives: [What do users do today instead? Spreadsheets, manual process, a different tool?]
  • Our differentiation: [What makes this project different or better for our target users?]

Links and notes:

  • [COMPETITOR_1_NAME]: [URL] — [brief note on what they do well / poorly]
  • [COMPETITOR_2_NAME]: [URL] — [brief note]

Constraints

[Real limitations that shape decisions. Budget, time, team size, technical constraints, regulatory requirements.]

  • [CONSTRAINT_1]
  • [CONSTRAINT_2]

Non-Goals

[What this project explicitly does NOT try to do. This is just as important as what it does — it prevents scope creep and keeps expectations clear.]

  • [NON_GOAL_1]
  • [NON_GOAL_2]

Known Risks

[What could go wrong? What are you uncertain about?]

  • [RISK_1]
  • [RISK_2]

Open Questions

[Things that are not yet decided. These are expected — not every answer is needed at kickoff. Items here will be resolved during development and tracked in tasks or ADRs as appropriate.]

  • [QUESTION_1]
  • [QUESTION_2]

Revision Log

[This section stays empty at kickoff. When a major direction change happens during the project, record it here with a date and brief explanation. Reference the relevant ADR if one was created.]