dev-diaryproject-managementlinearspecificationsplanningworkflow

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.

godegit Development Team
godegit Development Team
8 min read
Linear project board showing organized marketing site tickets

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:

MetricTarget
Value proposition clarity10 seconds to understand
Time to first command< 2 minutes from landing
Documentation findability3 clicks max
Lighthouse Performance90+
Lighthouse Accessibility95+
Command copy rate80%+ 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:

  1. Navigation Foundation (NRD-114): Site-wide navigation and routing
  2. Homepage Hero (NRD-104): Value proposition and first impressions
  3. 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

Tagged with

dev-diaryproject-managementlinearspecificationsplanningworkflow

Share this post

godegit Development Team

godegit Development Team

The engineering team behind godegit, sharing our approach to structured project planning and issue management.

Related Posts