It’s Tuesday morning. Your team lead pings you on Slack: “Hey, quick question—why did we decide to use WebSockets instead of polling for the notifications feature?”
You scroll back through three weeks of scattered messages, buried GIFs, and tangential conversations about lunch plans. Eventually you find a thread from 2 AM where someone suggested WebSockets, three people reacted with 👍, and… that was it. No documentation. No clear decision record. Just vibes and emojis.
If this sounds familiar, you’re not alone. Most development teams plan in the same places they chat—Slack, Discord, email threads, or hastily scribbled notes in Google Docs. It works until it doesn’t. Then you’re rebuilding context from memory, re-arguing decisions you already made, or worse—building features nobody actually asked for because requirements were never written down in the first place.
We’ve been there. So we built something different.
The Problem: Planning in Transit
Here’s what happens when planning lives in chat:
Lost Context: Someone asks “Why did we choose Postgres?” and nobody remembers because the conversation happened across five different channels over two weeks.
Scope Creep: Without clear boundaries, every “quick idea” turns into “we should also build…” and suddenly your two-week project is a three-month odyssey.
Misaligned Teams: Developers build what they think product wants. Product expects what design mocked up. Design assumed engineering would handle the hard parts. Everyone’s surprised when the demo doesn’t match expectations.
No Single Source of Truth: Requirements are in Jira. Design is in Figma. Decisions are in Slack. Architecture notes are in someone’s local markdown file. Good luck onboarding a new team member.
Zombie Projects: You return to a project after a month and spend two days remembering what you were doing, why you were doing it, and what you decided not to do.
We needed something better. Not another project management tool. Not another Kanban board. We needed a framework that made planning executable, documentation automatic, and context persistent.
The Solution: TRD-Driven Project Planning
We built a project startup template that treats planning like code: structured, version-controlled, and traceable. It’s built on a simple but powerful workflow:
TRD (Technical Requirements Document) → Canvas → Plan → Backlog → Status
Every project starts with a TRD—generated via ChatGPT—that defines what you’re building, who it’s for, and what success looks like. From there, you fill a lightweight canvas that answers the strategic questions (vision, goals, stakeholders, open questions). Then you break it down into a timeline plan (Now/Next/Later), create granular backlog items with acceptance criteria, and track progress in a live status document.
All of it lives in one place: a .assistant/ directory in your repo, tracked in Git, and structured for AI assistance at every step.
How It Works (The 10,000-Foot View)
1. Start with a TRD (Technical Requirements Document)
Before you write a single line of code, you write requirements. Not a 50-page waterfall spec—just a clear, structured document that answers:
- What are we building?
- Who is it for?
- What problems does it solve?
- What are the technical constraints?
You generate this using a ChatGPT prompt and refine it with your team. This becomes your North Star. Every feature, every backlog item, every decision traces back to the TRD.
2. Fill the Canvas (Context Alignment)
Next, you fill six lightweight files that capture strategic context:
- vision.md — Where are we going in 12 months?
- goals.md — What are we measuring? (SMART objectives)
- stakeholders.md — Who benefits? Who builds? Who approves?
- questions.md — What don’t we know yet?
- ideas.md — Brainstorming and inspiration
- notes.md — Observations and learnings
This takes 30 minutes and prevents weeks of misalignment. When product says “I thought we were targeting enterprise customers” and engineering says “I built this for solo developers,” you’ve failed the canvas step.
3. Create the Plan (Now/Next/Later)
Your plan is a simple timeline with three buckets:
- Now: What we’re building this sprint/week
- Next: What’s coming after that
- Later: Ideas we’re not committing to yet
This keeps you focused and prevents the “we should also build…” trap. If it’s not in Now, you’re not building it yet.
4. Break It Into a Backlog
Each Now item becomes a granular backlog task with:
- A unique ID (e.g.,
FEAT-001) - TRD reference (what requirement does this satisfy?)
- Priority and effort estimate
- Acceptance criteria (what does “done” look like?)
No vague tickets like “Implement notifications.” Instead: “Build WebSocket server that handles real-time message delivery with reconnection logic and 99.9% uptime SLA.”
5. Track Status (and Stay Honest)
Your status.md file is the single source of truth for progress. It includes:
- Focus: What you’re working on right now
- Risks: What could derail you
- Artifacts: Links to completed work, ADRs, documentation
- Open Questions: What’s uncertain or unresolved
Every work session updates this file. It’s how you quickly get back into context after a break. It’s how new team members understand what’s happening without reading 500 Slack messages.
Who This Is For
This framework works for:
Solo Developers: You’re juggling multiple projects and need to remember why you made decisions three months ago.
Small Teams (2-5 people): You’re moving fast but need alignment without heavyweight process.
Agencies: You’re building for clients and need clear documentation of what was agreed, what’s in scope, and what changed along the way.
Open Source Projects: You need contributors to understand the vision, goals, and decision history without hours of context-building.
It’s not for massive enterprise teams with formal PMOs and dedicated project coordinators. It’s for people who want to ship faster with better planning, without turning planning into a full-time job.
What Makes This Different
It’s Git-Native: All your planning lives in markdown files next to your code. Version control your decisions. Branch your planning. Merge changes from teammates.
It’s AI-Augmented: Every step has a ChatGPT prompt. Generate requirements, draft backlog items, propose architectural decisions. The AI doesn’t replace thinking—it accelerates it.
It’s Executable: This isn’t documentation for documentation’s sake. Every file feeds the next step. TRD → Canvas → Plan → Backlog → Code. It’s a pipeline, not a paper trail.
It Captures Decisions: Architecture Decision Records (ADRs) document why you chose Postgres, why you picked JWT auth, why you went serverless. Six months later, you’ll be grateful.
It’s Session-Based: Each work session has a kickoff (what am I doing?), execution (do the work), and wrap-up (what did I decide?). Context never evaporates.
What’s Next?
In the next post, we’ll dive deep into the TRD-first workflow—how to generate a Technical Requirements Document using ChatGPT, how it becomes your project’s North Star, and how to avoid the most common mistakes that derail planning from day one.
For now, here’s the core insight: planning doesn’t fail because teams don’t try—it fails because planning lives in the wrong places. When requirements, decisions, and context are scattered across chat apps, wikis, and someone’s brain, they evaporate. When they’re structured, version-controlled, and next to your code, they stick.
Stop planning in Slack. Start planning like you ship code.
Coming in Post 2: From ChatGPT to Code: The TRD-First Workflow — Learn how to generate a Technical Requirements Document in 20 minutes and use it as the foundation for everything you build.
Keywords: project planning, technical requirements document, TRD, project management for developers, AI-assisted planning, documentation framework