Dev Diary: Building godegit.dev - Phase 7: Project Planning & Issue Architecture
How we structured our marketing site development with spec-driven workflows and Linear project management. From user stories to actionable tickets with clear dependencies.


Structured project planning: from spec to actionable issues
From Vision to Execution: Structuring the Marketing Site Build
Welcome back to the godegit.dev development diary! Phase 7 marks a shift from building features to building the right features. Before writing a single line of new code, we invested in proper project planning infrastructure using spec-driven development and Linear for issue tracking.
This phase taught us that great software starts with great specifications. The time spent on structured planning pays dividends throughout development.
The Planning Challenge
Building a marketing site sounds simple, but doing it well requires answering many questions:
- What does "good" look like for developer discovery?
- How do we prioritize between SEO, accessibility, and features?
- What's the logical order of implementation?
- How do we track progress across multiple work streams?
Our solution: spec-driven development with structured issue management.
Specification-First Approach
User Stories as Foundation
We started by identifying six core user scenarios, each with clear priorities:
Priority 1 (Critical Path)
- Discover What godegit Does: First impressions within 10 seconds
- Install and Get Started: Friction-free adoption path
Priority 2 (Retention)
- Learn Detailed Usage: Comprehensive documentation
- Understand Licensing: Trust-building for professional use
Priority 3 (Differentiation)
- Compare to Alternatives: Informed decision support
- Find Community & Support: Long-term engagement
Each user story included acceptance scenarios written in Given/When/Then format, making them directly testable.
Functional Requirements Mapping
We derived 22 functional requirements from the user stories, each with a clear identifier:
## Homepage & Value Proposition
- FR-001: Clear headline within viewport on load
- FR-002: 3-4 key benefits displayed
- FR-003: Concrete use cases shown
- FR-004: Prominent installation CTA
## Installation & Quick Start
- FR-005: Copy-to-clipboard commands for 3+ platforms
- FR-006: Quick start example with output
- FR-007: Recommended method indicators
## Documentation
- FR-008: Complete command reference
- FR-009: Examples with expected output
- FR-010: Navigable structure
- FR-011: Searchable/browsable by topic
## Technical Requirements
- FR-019: Fully responsive design
- FR-020: WCAG 2.1 AA compliance
- FR-021: Core content without JavaScript
- FR-022: SEO and social meta tags
Success Criteria
Every requirement tied back to measurable outcomes:
| Metric | Target |
|---|---|
| Value proposition clarity | 10 seconds to understand |
| Time to first command | < 2 minutes from landing |
| Documentation findability | 3 clicks max |
| Lighthouse Performance | 90+ |
| Lighthouse Accessibility | 95+ |
| Command copy rate | 80%+ of visitors |
Linear Issue Architecture
From Requirements to Tickets
We translated the specification into 12 actionable Linear issues, grouped by logical work units:
Core Content (Priority: Urgent)
- NRD-104: Homepage Hero & Value Proposition Section
- NRD-105: Installation & Quick Start Section
Documentation (Priority: High)
- NRD-106: Documentation Section & Navigation
- NRD-107: Licensing & Attribution Documentation
- NRD-114: Site Navigation & Deep Link Support
Technical Foundation (Priority: High)
- NRD-110: Responsive Design & Mobile Experience
- NRD-111: Accessibility Compliance (WCAG 2.1 AA)
Enhancement (Priority: Medium)
- NRD-108: Comparison Page
- NRD-109: Community & Support Section
- NRD-112: Progressive Enhancement & No-JS
- NRD-113: SEO & Social Sharing Meta Tags
- NRD-115: Documentation Content Maintainability
Dependency Management
Issues aren't isolated - they have logical dependencies:
NRD-114 (Navigation)
├── NRD-106 (Docs) ─── NRD-107 (Licensing)
└── NRD-109 (Community)
NRD-104 (Hero)
└── NRD-108 (Comparison)
This ensures we build foundational components before features that depend on them.
Issue Structure
Each issue follows a consistent template:
## Overview
[Brief description of the work unit]
## User Story
> [The user perspective this addresses]
## Requirements
- **FR-XXX**: [Specific requirement]
- **FR-XXX**: [Specific requirement]
## Acceptance Criteria
- [ ] Testable criterion 1
- [ ] Testable criterion 2
## Success Metric
[Measurable outcome from spec]
This structure ensures every piece of work traces back to user value.
Project Board Organization
Labels for Filtering
We use consistent labels across issues:
- Feature: New functionality
- Frontend: Vue/Nuxt work
- Improvement: Enhancements to existing features
Priority Mapping
Linear priorities map to our spec priorities:
- Urgent (P1): Core user journey
- High (P2): Retention features
- Medium (P3): Differentiation features
Status Workflow
Simple, clear status progression:
Backlog → Todo → In Progress → In Review → Done
Benefits of This Approach
1. Clear Scope Boundaries
Each issue has explicit acceptance criteria. No scope creep, no "while we're at it" additions that delay delivery.
2. Parallel Workstreams
With dependencies mapped, multiple developers can work simultaneously on non-blocking issues.
3. Progress Visibility
Stakeholders can track progress at the user story level without getting lost in implementation details.
4. Quality Gates
Acceptance criteria become the definition of done. PRs can be reviewed against specific requirements.
5. Documentation as Artifact
The spec and issues together document why decisions were made, not just what was built.
Lessons Learned
Invest in Specification
The time spent writing clear requirements saved far more time during implementation. Ambiguity is expensive.
Map Dependencies Early
Understanding what blocks what prevents rework and enables parallel execution.
Keep Issues Focused
Each issue should be completable in 1-3 days. Larger work gets broken down further.
Trace to User Value
Every technical requirement should connect to a user story. If it doesn't, question whether it's needed.
What's Next
With our planning infrastructure in place, Phase 8 will begin implementation:
- Navigation Foundation (NRD-114): Site-wide navigation and routing
- Homepage Hero (NRD-104): Value proposition and first impressions
- Installation Section (NRD-105): Developer onboarding flow
The spec and issues ensure we'll build the right thing, in the right order, with the right quality bar.
Next time, we'll dive into implementation, starting with the navigation foundation that enables everything else.
Project Board:
View our Linear projectSpecification: See specs/001-marketing-site/spec.md in the repository

