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 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?]
[How do you know this project succeeded? Be concrete.]
- [CRITERION_1]
- [CRITERION_2]
- [CRITERION_3]
[The main capabilities the product must have. Keep it focused — 3 to 7 items.]
- [FEATURE_1]
- [FEATURE_2]
- [FEATURE_3]
[The key journeys a user takes through the product. Describe the most important 2-3 flows.]
- [STEP_1]
- [STEP_2]
- [STEP_3]
- [STEP_1]
- [STEP_2]
- [STEP_3]
- 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]
[High-level phases, not detailed task lists. Each phase should have a clear goal.]
- Goal: [What does "done" look like for this phase?]
- Scope: [What's included?]
- Goal: [What does "done" look like for this phase?]
- Scope: [What's included?]
- Goal: [What does "done" look like for this phase?]
- Scope: [What's included?]
[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]
[Real limitations that shape decisions. Budget, time, team size, technical constraints, regulatory requirements.]
- [CONSTRAINT_1]
- [CONSTRAINT_2]
[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]
[What could go wrong? What are you uncertain about?]
- [RISK_1]
- [RISK_2]
[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]
[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.]