Usamos cookies para mejorar tu experiencia en el sitio
CodeWorlds
Volver a colecciones
Guide29 min read

Get Shit Done

Methodology and mindset for maximum productivity with AI assistants. Practical approach to programming with Claude, Cursor and other AI tools.

Get Shit Done - AI Productivity

Czym jest Get Shit Done?

Get Shit Done (GSD) to filozofia i podejście do programowania z AI, które maksymalizuje output przy minimalnym tarciu. To nie framework ani narzędzie - to mindset. Mniej perfekcjonizmu, więcej iteracji. Mniej planowania, więcej działania. AI jako force multiplier, nie jako zastępca myślenia.

GSD powstało jako odpowiedź na nowy paradygmat programowania, gdzie AI assistants (Claude Code, Cursor, GitHub Copilot) fundamentalnie zmieniają sposób, w jaki tworzymy oprogramowanie. Stare zasady - "measure twice, cut once", "plan everything upfront" - nie zawsze mają sens, gdy koszt generowania kodu spadł o rząd wielkości.

Manifest GSD

Code
TEXT
1. Działaj szybko, iteruj jeszcze szybciej
2. Perfekcja to wróg postępu
3. AI robi commodity work, Ty robisz creative work
4. Feedback > planowanie
5. Ship today, improve tomorrow
6. Context is king
7. Każdy problem ma szybkie rozwiązanie

Kto powinien stosować GSD?

  • Indie hackers budujący MVPs
  • Startup founders walidujący pomysły
  • Solo devs z ograniczonym czasem
  • Teams chcący przyspieszyć development
  • Wszyscy zmęczeni over-engineeringiem

Kto NIE powinien stosować GSD (bezpośrednio)?

  • Systemy safety-critical (lotnictwo, medycyna)
  • Infrastruktura finansowa (core banking)
  • Projekty z regulacjami compliance
  • Sytuacje gdzie błąd = katastrofa

Nawet w tych przypadkach elementy GSD można stosować do prototypowania i eksploracji.

Zasady Get Shit Done

1. Start Imperfect

Code
TEXT
❌ "Let me plan the perfect architecture first..."
✅ "Create a basic version that works, then improve"

❌ "I need to research all possible approaches..."
✅ "Try the simplest approach, pivot if needed"

❌ "This needs to be scalable from day one..."
✅ "Make it work for 10 users, then 100, then 1000"

Dlaczego to działa:

Koszt generowania kodu z AI jest niski. Koszt długiego planowania jest wysoki. Lepiej wygenerować 3 wersje i wybrać najlepszą niż planować idealną wersję przez tydzień.

Przykład:

Code
TypeScript
// Zamiast projektować idealny system autoryzacji...

// Krok 1: Zrób najprostszą rzecz która działa
const isAdmin = (userId: string) => userId === process.env.ADMIN_ID

// Krok 2: Gdy potrzebujesz więcej, rozszerz
const hasPermission = (userId: string, permission: string) => {
  const user = await getUser(userId)
  return user.permissions.includes(permission)
}

// Krok 3: Gdy potrzebujesz RBAC, przebuduj
// ... ale dopiero gdy naprawdę potrzebujesz

2. Delegate to AI

Code
TEXT
❌ Pisz boilerplate ręcznie
✅ "Generate CRUD for User model with validation"

❌ Ręcznie konwertuj typy
✅ "Generate TypeScript types from this JSON"

❌ Pisz dokumentację od zera
✅ "Add JSDoc comments to these functions"

❌ Ręcznie refaktoruj
✅ "Refactor this to use async/await instead of callbacks"

Co delegować do AI:

  1. Boilerplate - CRUD, formularze, API endpoints
  2. Konwersje - JSON→Types, SQL→ORM, REST→GraphQL
  3. Dokumentacja - JSDoc, README, komentarze
  4. Testy - Unit tests, test cases, mocks
  5. Refactoring - Style changes, pattern migration

Co NIE delegować:

  1. Decyzje architektoniczne - AI nie zna Twojego kontekstu biznesowego
  2. Wybór technologii - AI nie wie, co Twój team zna
  3. Priorytetyzacja - AI nie wie, co jest ważne dla użytkowników
  4. Review - Zawsze sprawdzaj wygenerowany kod

3. Context is King

Code
TEXT
❌ "Fix the bug"
✅ "Fix the null pointer in useAuth.ts:45.
    The user object is undefined when session expires.
    Expected: Show login modal. Actual: White screen."

❌ "Add tests"
✅ "Add unit tests for calculateDiscount function in pricing.ts.
    Cover: normal price, bulk discount (>10 items),
    VIP discount, combined discounts, edge cases (0, negative)."

❌ "Make it better"
✅ "Optimize this query - currently takes 2s for 10k rows.
    Table has indexes on user_id and created_at.
    Most queries filter by user_id + date range."

Template dla dobrych promptów:

Code
Markdown
## Task
[Co chcesz osiągnąć]

## Context
[Relevantne informacje o kodzie/projekcie]

## Current State
[Jak to działa teraz]

## Expected State
[Jak ma działać]

## Constraints
[Ograniczenia, technologie, patterns]

Przykład:

Code
Markdown
## Task
Add pagination to the products list

## Context
- Next.js 15 App Router
- PostgreSQL + Prisma
- Currently fetching all products (slow for 10k+ items)

## Current State
\`\`\`typescript
const products = await prisma.product.findMany()
\`\`\`

## Expected State
- Server-side pagination
- 20 items per page
- URL-based page state (?page=2)
- Total count for pagination UI

## Constraints
- Keep as Server Component
- Use existing Prisma setup
- Match current UI design (shadcn/ui)

4. Iterate Fast

Code
TEXT
Standard flow:
1. Opisz co chcesz (30 sekund)
2. AI generuje kod (10 sekund)
3. Testuj natychmiast (60 sekund)
4. Feedback do AI (30 sekund)
5. Repeat

Cykl: ~2 minuty per iteracja
10 iteracji: 20 minut do working feature

Versus tradycyjne podejście:

Code
TEXT
1. Zaplanuj architekturę (2 godziny)
2. Napisz kod (4 godziny)
3. Debug (2 godziny)
4. Refactor (2 godziny)
5. Test (1 godzina)

Total: ~11 godzin do working feature

Klucz do szybkich iteracji:

  1. Małe zmiany - Jedna rzecz na raz
  2. Natychmiastowy feedback - Hot reload, live preview
  3. Konkretny feedback - "Line 45 throws TypeError" > "It doesn't work"
  4. Brak przywiązania - Gotów odrzucić i zacząć od nowa

5. Ship Today, Improve Tomorrow

Code
TEXT
Day 1: Ship working MVP
Day 2: Fix critical bugs from user feedback
Day 3: Add most requested feature
Day 7: Refactor based on real usage patterns
Day 30: Optimize performance bottlenecks

NIE:
Month 1: Plan perfect architecture
Month 2: Build perfect architecture
Month 3: Realize users wanted something else

"Shippable" checklist:

  • Core functionality works
  • No data loss scenarios
  • Basic error handling
  • Works on target devices
  • User can complete main flow

"Perfect" can wait:

  • 100% test coverage
  • Perfect performance
  • All edge cases handled
  • Beautiful animations
  • Comprehensive docs

6. Every Problem Has a Fast Solution

Code
TEXT
❌ "This will take weeks to implement properly"
✅ "What's the fastest way to validate this idea?"

❌ "We need a custom solution"
✅ "Is there a library/service that does 80% of this?"

❌ "This requires a complex algorithm"
✅ "What's the naive solution? Is it good enough?"

Decision framework:

Code
TEXT
1. Czy istnieje gotowa biblioteka? → Użyj jej
2. Czy można użyć SaaS? → Zintegruj
3. Czy naive solution wystarczy? → Zaimplementuj
4. Czy AI może wygenerować? → Deleguj
5. Dopiero wtedy → Buduj custom

Przykłady szybkich rozwiązań:

Problem"Proper" solutionGSD solution
AuthCustom JWT + RBACNextAuth/Clerk
PaymentsCustom integrationStripe Checkout
SearchElasticsearch clusterAlgolia/Typesense
EmailSMTP + templatesResend/Postmark
CMSCustom admin panelSanity/Contentful
AnalyticsCustom trackingPlausible/PostHog

GSD Workflow

Morning Setup (10 min)

Code
Bash
# 1. Review what needs to be done
cat TODO.md  # or check Linear/Notion

# 2. Pick ONE high-impact item
# Ask: "What will move the needle most today?"

# 3. Time-box it
# "I'll spend max 2 hours on this"

# 4. Start Claude Code
claude

Working Session Structure

Code
TEXT
[0:00-0:05] Define the task clearly
[0:05-0:10] Gather context (files, errors, requirements)
[0:10-0:50] Iterate with AI (5-10 cycles)
[0:50-0:55] Test thoroughly
[0:55-1:00] Commit and document

Break 10 min

Repeat

AI Prompting Patterns

Implementation Request

Code
Markdown
Implement [feature] that:
- Does X
- Handles Y edge case
- Uses existing [pattern] from [file]
- Follows our conventions (TypeScript strict, Tailwind, etc.)

Start with the simplest working version.

Debug Request

Code
Markdown
Debug [issue]:
- Expected: [behavior]
- Actual: [behavior]
- Steps to reproduce: [steps]
- Relevant code: [file:line]
- Error message: [error]

I've already tried: [attempts]

Refactor Request

Code
Markdown
Refactor [code] to:
- Improve [specific aspect]
- Maintain backward compatibility
- Keep same public API

Don't change: [what to preserve]
Constraints: [limits]

Review Request

Code
Markdown
Review this code for:
- Bugs and edge cases
- Security issues
- Performance problems
- Code quality

Be critical. I want to ship this today.

Quick Wins Catalog

Code
TypeScript
// 1. Generate types from API response
"Generate TypeScript interfaces from this JSON response"

// 2. Write tests for existing code
"Write unit tests for this function, cover edge cases"

// 3. Add error handling
"Add proper error handling with user-friendly messages"

// 4. Optimize component
"This component re-renders too often, optimize it"

// 5. Add loading states
"Add loading and error states to this data-fetching component"

// 6. Create form from schema
"Generate a form component from this Zod schema"

// 7. Add documentation
"Add JSDoc comments to exported functions in this file"

// 8. Convert patterns
"Convert this callback-based code to async/await"

// 9. Add validation
"Add input validation using Zod for this API endpoint"

// 10. Create tests
"Generate test cases for this function based on its types"

Tools dla GSD

AI Coding Assistants

ToolBest forCost
Claude CodeComplex tasks, terminal workflow$20/mo (Pro)
CursorIDE integration, inline edits$20/mo
GitHub CopilotQuick completions$10/mo
v0UI component generationFree tier
Bolt.newFull app scaffoldingFree tier

Productivity Stack

Code
TEXT
Code:        Claude Code / Cursor
UI:          v0.dev → shadcn/ui
Backend:     Supabase / Convex / Firebase
Deploy:      Vercel / Railway
Auth:        Clerk / NextAuth
Payments:    Stripe
Analytics:   Plausible / PostHog
Monitoring:  Sentry

GSD Aliases

Code
Bash
# .bashrc / .zshrc

# Quick Claude Code
alias c="claude"
alias cc="claude --continue"

# Quick git
alias gs="git status"
alias gc="git commit -m"
alias gp="git push"
alias gcp="git add -A && git commit -m 'wip' && git push"

# Quick npm
alias d="npm run dev"
alias b="npm run build"
alias t="npm test"

# Quick directories
alias p="cd ~/projects"

Metryki GSD

Co mierzyć

Code
TEXT
✅ Features shipped per week
✅ Time to first working version
✅ User feedback response time
✅ Bugs caught before production
✅ Iteration cycles per feature

❌ Lines of code written
❌ Hours worked
❌ Commits per day
❌ Test coverage %
❌ Code complexity metrics

Weekly Review Template

Code
Markdown
## Week of [Date]

### Shipped
- [ ] Feature A (impact: high, effort: medium)
- [ ] Fix B (impact: medium, effort: low)
- [ ] Improvement C (impact: low, effort: low)

### Learnings
- What worked well:
- What slowed me down:
- What to try next week:

### Blockers removed
- [blocker] → [solution]

### Next week priorities
1. [Most impactful item]
2. [Second priority]
3. [Nice to have]

Mindset Shifts

From Perfectionism to Progress

Code
TEXT
Old: "This code needs to be perfect before I ship"
New: "This code needs to work before I ship"

Old: "I'll add all features users might need"
New: "I'll add features users actually ask for"

Old: "Let me research the best approach"
New: "Let me try the simplest approach"

From Planning to Doing

Code
TEXT
Old: "Let me write a detailed spec first"
New: "Let me build a prototype first"

Old: "We need a meeting to discuss this"
New: "Let me try it and show you the result"

Old: "I'll estimate how long this will take"
New: "I'll time-box it and see how far I get"

From Solo to AI-Assisted

Code
TEXT
Old: "I need to figure this out myself"
New: "Let me ask AI for options, then decide"

Old: "Writing tests is tedious"
New: "AI writes tests, I review them"

Old: "Documentation takes forever"
New: "AI documents, I verify accuracy"

Key Mantras

Code
TEXT
"Done is better than perfect"
"Ship today, improve tomorrow"
"AI handles breadth, you handle depth"
"Every problem has a fast solution"
"Progress over perfection"
"Feedback over speculation"
"Working code beats documentation"

Common Objections

"But what about code quality?"

Code quality matters, ale:

  • Quality bez shipping = 0 value
  • Shippable code > perfect code in drawer
  • Iteracja poprawia quality naturalnie
  • AI-generated code często jest clean

GSD approach:

  1. Ship working version
  2. Get real feedback
  3. Improve based on usage
  4. Refactor when patterns emerge

"But what about technical debt?"

Technical debt istnieje, ale:

  • Nie-shipped code to też "debt" (opportunity cost)
  • Wczesny feedback redukuje wrong decisions
  • Łatwiej refaktorować mały, working system

GSD approach:

  1. Accept some debt for speed
  2. Track debt explicitly (TODO comments, issues)
  3. Pay down debt in dedicated sessions
  4. Don't let debt block shipping

"But what about tests?"

Tests są ważne, ale:

  • 100% coverage przed shipem = slow
  • Real users znajdą bugs szybciej niż unit tests
  • AI może generować testy po fakcie

GSD approach:

  1. Critical paths: test first
  2. Rest: test after shipping, based on bugs
  3. Use AI to generate test cases
  4. Integration tests > unit tests for MVP

"But what about security?"

Security jest krytyczne, ale:

  • Większość MVPs nie jest target'em ataków
  • Standard practices (auth, HTTPS, validation) są szybkie
  • Audit przed scaling, nie przed launch

GSD approach:

  1. Use proven auth (NextAuth, Clerk)
  2. Use HTTPS always
  3. Validate all inputs
  4. Don't store sensitive data unnecessarily
  5. Security audit przed significance scale

Case Studies

Case Study 1: MVP w weekend

Code
TEXT
Problem: Walidacja pomysłu na SaaS

Friday evening:
- Idea: Tool do śledzenia nawyków
- Stack: Next.js + Supabase + Vercel

Saturday:
- Morning: Auth + basic data model (Supabase)
- Afternoon: Core UI (v0 → shadcn/ui)
- Evening: CRUD operations + basic charts

Sunday:
- Morning: Polish UI, add onboarding
- Afternoon: Set up Stripe (simple pricing)
- Evening: Deploy to Vercel, buy domain

Monday:
- Share na Twitter, ProductHunt, Reddit
- First 10 users signed up
- Real feedback started flowing

Total: ~20 hours to shipped MVP

Case Study 2: Feature w godzinę

Code
TEXT
Problem: Add export to PDF dla raportów

Traditional approach (estimated: 2 days):
- Research PDF libraries
- Design export format
- Implement generation
- Handle edge cases
- Test thoroughly

GSD approach (actual: 1 hour):

[0:00] "Add PDF export to this report component.
       Use react-pdf or similar. Match current styling."

[0:10] AI generates working version

[0:20] Test with real data, find edge cases

[0:30] "Fix: long text overflows, images missing"

[0:40] Iterate 2 more times

[0:50] Final testing

[1:00] Commit and deploy

Result: Users can export PDFs

Checklista na start

Przed projektem

  • Zdefiniuj JEDNĄ metrykę sukcesu
  • Określ MVP scope (co MUSI działać)
  • Wybierz stack (czas decyzji: max 30 min)
  • Setup repo z CLAUDE.md

Podczas buildu

  • Time-box każde zadanie
  • Używaj AI do boilerplate
  • Testuj często, małe zmiany
  • Ship codziennie (lub co 2 dni max)

Po shipie

  • Zbieraj feedback aktywnie
  • Reaguj na bugs w <24h
  • Priorytetyzuj based on data
  • Celebrate wins 🎉

Cennik narzędzi GSD

ToolFree tierPro
Claude Code$20/mo
Cursor2 weeks$20/mo
GitHub CopilotStudents$10/mo
v0200 credits$20/mo
VercelHobby$20/mo
Supabase500MB$25/mo

Minimal GSD stack cost: ~$50-100/mo

FAQ - Najczęściej zadawane pytania

Czy GSD to tylko dla side projects?

Nie, GSD działa w każdym kontekście gdzie:

  • Szybki feedback jest wartościowy
  • Iteracja jest możliwa
  • Perfect nie jest wymogiem compliance

W corporate możesz stosować GSD do prototypów, MVPs, internal tools.

Jak przekonać team do GSD?

  1. Zacznij od siebie - pokaż wyniki
  2. Użyj na małym projekcie jako proof
  3. Mierz i pokazuj metryki (time to ship)
  4. Stopniowo wprowadzaj praktyki

Co gdy AI generuje zły kod?

  1. Daj lepszy kontekst
  2. Podziel na mniejsze zadania
  3. Poproś o wyjaśnienie podejścia
  4. Iteruj z konkretnym feedbackiem
  5. Jeśli nie działa - napisz sam ten kawałek

Jak balansować GSD z "proper engineering"?

Code
TEXT
Faza 1 (MVP): 100% GSD
Faza 2 (PMF): 70% GSD, 30% engineering
Faza 3 (Scale): 50% GSD, 50% engineering
Faza 4 (Mature): 30% GSD, 70% engineering

GSD służy do szybkiego odkrywania co budować. Engineering służy do budowania tego dobrze.

Czy GSD to to samo co "vibecoding"?

Podobne filozofie, różne akcenty:

  • Vibecoding: Flow state, intuition, creative coding
  • GSD: Outcome-focused, metric-driven, shipping

Możesz łączyć oba - vibecoding to GSD w flow state.

Jak uniknąć wypalenia przy szybkim tempie?

  1. Time-box sesje (max 4h focused work)
  2. Celebruj małe wins
  3. Rób regularne przerwy
  4. Nie pracuj w weekendy (chyba że to passion project)
  5. Ship consistently > ship constantly

Get Shit Done - AI Productivity

What is Get Shit Done?

Get Shit Done (GSD) is a philosophy and approach to programming with AI that maximizes output with minimal friction. It is not a framework or a tool - it is a mindset. Less perfectionism, more iteration. Less planning, more doing. AI as a force multiplier, not as a replacement for thinking.

GSD emerged as a response to the new programming paradigm, where AI assistants (Claude Code, Cursor, GitHub Copilot) fundamentally change the way we build software. Old rules - "measure twice, cut once", "plan everything upfront" - do not always make sense when the cost of generating code has dropped by an order of magnitude.

GSD manifesto

Code
TEXT
1. Act fast, iterate even faster
2. Perfection is the enemy of progress
3. AI does commodity work, you do creative work
4. Feedback > planning
5. Ship today, improve tomorrow
6. Context is king
7. Every problem has a fast solution

Who should use GSD?

  • Indie hackers building MVPs
  • Startup founders validating ideas
  • Solo devs with limited time
  • Teams wanting to accelerate development
  • Everyone tired of over-engineering

Who should NOT use GSD (directly)?

  • Safety-critical systems (aviation, medicine)
  • Financial infrastructure (core banking)
  • Projects with compliance regulations
  • Situations where a bug = catastrophe

Even in these cases, elements of GSD can be applied to prototyping and exploration.

Get Shit Done principles

1. Start Imperfect

Code
TEXT
❌ "Let me plan the perfect architecture first..."
✅ "Create a basic version that works, then improve"

❌ "I need to research all possible approaches..."
✅ "Try the simplest approach, pivot if needed"

❌ "This needs to be scalable from day one..."
✅ "Make it work for 10 users, then 100, then 1000"

Why this works:

The cost of generating code with AI is low. The cost of prolonged planning is high. It is better to generate 3 versions and pick the best one than to plan the ideal version for a week.

Example:

Code
TypeScript
// Instead of designing a perfect authorization system...

// Step 1: Do the simplest thing that works
const isAdmin = (userId: string) => userId === process.env.ADMIN_ID

// Step 2: When you need more, extend
const hasPermission = (userId: string, permission: string) => {
  const user = await getUser(userId)
  return user.permissions.includes(permission)
}

// Step 3: When you need RBAC, rebuild
// ... but only when you actually need it

2. Delegate to AI

Code
TEXT
❌ Write boilerplate manually
✅ "Generate CRUD for User model with validation"

❌ Convert types by hand
✅ "Generate TypeScript types from this JSON"

❌ Write documentation from scratch
✅ "Add JSDoc comments to these functions"

❌ Refactor manually
✅ "Refactor this to use async/await instead of callbacks"

What to delegate to AI:

  1. Boilerplate - CRUD, forms, API endpoints
  2. Conversions - JSON→Types, SQL→ORM, REST→GraphQL
  3. Documentation - JSDoc, README, comments
  4. Tests - Unit tests, test cases, mocks
  5. Refactoring - Style changes, pattern migration

What NOT to delegate:

  1. Architectural decisions - AI does not know your business context
  2. Technology choices - AI does not know what your team is familiar with
  3. Prioritization - AI does not know what matters to your users
  4. Review - Always verify generated code

3. Context is King

Code
TEXT
❌ "Fix the bug"
✅ "Fix the null pointer in useAuth.ts:45.
    The user object is undefined when session expires.
    Expected: Show login modal. Actual: White screen."

❌ "Add tests"
✅ "Add unit tests for calculateDiscount function in pricing.ts.
    Cover: normal price, bulk discount (>10 items),
    VIP discount, combined discounts, edge cases (0, negative)."

❌ "Make it better"
✅ "Optimize this query - currently takes 2s for 10k rows.
    Table has indexes on user_id and created_at.
    Most queries filter by user_id + date range."

Template for good prompts:

Code
Markdown
## Task
[What you want to achieve]

## Context
[Relevant information about the code/project]

## Current State
[How it works now]

## Expected State
[How it should work]

## Constraints
[Limitations, technologies, patterns]

Example:

Code
Markdown
## Task
Add pagination to the products list

## Context
- Next.js 15 App Router
- PostgreSQL + Prisma
- Currently fetching all products (slow for 10k+ items)

## Current State
\`\`\`typescript
const products = await prisma.product.findMany()
\`\`\`

## Expected State
- Server-side pagination
- 20 items per page
- URL-based page state (?page=2)
- Total count for pagination UI

## Constraints
- Keep as Server Component
- Use existing Prisma setup
- Match current UI design (shadcn/ui)

4. Iterate fast

Code
TEXT
Standard flow:
1. Describe what you want (30 seconds)
2. AI generates code (10 seconds)
3. Test immediately (60 seconds)
4. Feedback to AI (30 seconds)
5. Repeat

Cycle: ~2 minutes per iteration
10 iterations: 20 minutes to a working feature

Versus the traditional approach:

Code
TEXT
1. Plan architecture (2 hours)
2. Write code (4 hours)
3. Debug (2 hours)
4. Refactor (2 hours)
5. Test (1 hour)

Total: ~11 hours to a working feature

Keys to fast iteration:

  1. Small changes - One thing at a time
  2. Immediate feedback - Hot reload, live preview
  3. Specific feedback - "Line 45 throws TypeError" > "It doesn't work"
  4. No attachment - Ready to discard and start over

5. Ship today, improve tomorrow

Code
TEXT
Day 1: Ship working MVP
Day 2: Fix critical bugs from user feedback
Day 3: Add most requested feature
Day 7: Refactor based on real usage patterns
Day 30: Optimize performance bottlenecks

NOT:
Month 1: Plan perfect architecture
Month 2: Build perfect architecture
Month 3: Realize users wanted something else

"Shippable" checklist:

  • Core functionality works
  • No data loss scenarios
  • Basic error handling
  • Works on target devices
  • User can complete main flow

"Perfect" can wait:

  • 100% test coverage
  • Perfect performance
  • All edge cases handled
  • Beautiful animations
  • Comprehensive docs

6. Every problem has a fast solution

Code
TEXT
❌ "This will take weeks to implement properly"
✅ "What's the fastest way to validate this idea?"

❌ "We need a custom solution"
✅ "Is there a library/service that does 80% of this?"

❌ "This requires a complex algorithm"
✅ "What's the naive solution? Is it good enough?"

Decision framework:

Code
TEXT
1. Is there a ready-made library? → Use it
2. Can you use a SaaS? → Integrate it
3. Is a naive solution good enough? → Implement it
4. Can AI generate it? → Delegate
5. Only then → Build custom

Examples of fast solutions:

Problem"Proper" solutionGSD solution
AuthCustom JWT + RBACNextAuth/Clerk
PaymentsCustom integrationStripe Checkout
SearchElasticsearch clusterAlgolia/Typesense
EmailSMTP + templatesResend/Postmark
CMSCustom admin panelSanity/Contentful
AnalyticsCustom trackingPlausible/PostHog

GSD workflow

Morning setup (10 min)

Code
Bash
# 1. Review what needs to be done
cat TODO.md  # or check Linear/Notion

# 2. Pick ONE high-impact item
# Ask: "What will move the needle most today?"

# 3. Time-box it
# "I'll spend max 2 hours on this"

# 4. Start Claude Code
claude

Working session structure

Code
TEXT
[0:00-0:05] Define the task clearly
[0:05-0:10] Gather context (files, errors, requirements)
[0:10-0:50] Iterate with AI (5-10 cycles)
[0:50-0:55] Test thoroughly
[0:55-1:00] Commit and document

Break 10 min

Repeat

AI prompting patterns

Implementation request

Code
Markdown
Implement [feature] that:
- Does X
- Handles Y edge case
- Uses existing [pattern] from [file]
- Follows our conventions (TypeScript strict, Tailwind, etc.)

Start with the simplest working version.

Debug request

Code
Markdown
Debug [issue]:
- Expected: [behavior]
- Actual: [behavior]
- Steps to reproduce: [steps]
- Relevant code: [file:line]
- Error message: [error]

I've already tried: [attempts]

Refactor request

Code
Markdown
Refactor [code] to:
- Improve [specific aspect]
- Maintain backward compatibility
- Keep same public API

Don't change: [what to preserve]
Constraints: [limits]

Review request

Code
Markdown
Review this code for:
- Bugs and edge cases
- Security issues
- Performance problems
- Code quality

Be critical. I want to ship this today.

Quick wins catalog

Code
TypeScript
// 1. Generate types from API response
"Generate TypeScript interfaces from this JSON response"

// 2. Write tests for existing code
"Write unit tests for this function, cover edge cases"

// 3. Add error handling
"Add proper error handling with user-friendly messages"

// 4. Optimize component
"This component re-renders too often, optimize it"

// 5. Add loading states
"Add loading and error states to this data-fetching component"

// 6. Create form from schema
"Generate a form component from this Zod schema"

// 7. Add documentation
"Add JSDoc comments to exported functions in this file"

// 8. Convert patterns
"Convert this callback-based code to async/await"

// 9. Add validation
"Add input validation using Zod for this API endpoint"

// 10. Create tests
"Generate test cases for this function based on its types"

GSD tools

AI coding assistants

ToolBest forCost
Claude CodeComplex tasks, terminal workflow$20/mo (Pro)
CursorIDE integration, inline edits$20/mo
GitHub CopilotQuick completions$10/mo
v0UI component generationFree tier
Bolt.newFull app scaffoldingFree tier

Productivity stack

Code
TEXT
Code:        Claude Code / Cursor
UI:          v0.dev → shadcn/ui
Backend:     Supabase / Convex / Firebase
Deploy:      Vercel / Railway
Auth:        Clerk / NextAuth
Payments:    Stripe
Analytics:   Plausible / PostHog
Monitoring:  Sentry

GSD aliases

Code
Bash
# .bashrc / .zshrc

# Quick Claude Code
alias c="claude"
alias cc="claude --continue"

# Quick git
alias gs="git status"
alias gc="git commit -m"
alias gp="git push"
alias gcp="git add -A && git commit -m 'wip' && git push"

# Quick npm
alias d="npm run dev"
alias b="npm run build"
alias t="npm test"

# Quick directories
alias p="cd ~/projects"

GSD metrics

What to measure

Code
TEXT
✅ Features shipped per week
✅ Time to first working version
✅ User feedback response time
✅ Bugs caught before production
✅ Iteration cycles per feature

❌ Lines of code written
❌ Hours worked
❌ Commits per day
❌ Test coverage %
❌ Code complexity metrics

Weekly review template

Code
Markdown
## Week of [Date]

### Shipped
- [ ] Feature A (impact: high, effort: medium)
- [ ] Fix B (impact: medium, effort: low)
- [ ] Improvement C (impact: low, effort: low)

### Learnings
- What worked well:
- What slowed me down:
- What to try next week:

### Blockers removed
- [blocker] → [solution]

### Next week priorities
1. [Most impactful item]
2. [Second priority]
3. [Nice to have]

Mindset shifts

From perfectionism to progress

Code
TEXT
Old: "This code needs to be perfect before I ship"
New: "This code needs to work before I ship"

Old: "I'll add all features users might need"
New: "I'll add features users actually ask for"

Old: "Let me research the best approach"
New: "Let me try the simplest approach"

From planning to doing

Code
TEXT
Old: "Let me write a detailed spec first"
New: "Let me build a prototype first"

Old: "We need a meeting to discuss this"
New: "Let me try it and show you the result"

Old: "I'll estimate how long this will take"
New: "I'll time-box it and see how far I get"

From solo to AI-assisted

Code
TEXT
Old: "I need to figure this out myself"
New: "Let me ask AI for options, then decide"

Old: "Writing tests is tedious"
New: "AI writes tests, I review them"

Old: "Documentation takes forever"
New: "AI documents, I verify accuracy"

Key mantras

Code
TEXT
"Done is better than perfect"
"Ship today, improve tomorrow"
"AI handles breadth, you handle depth"
"Every problem has a fast solution"
"Progress over perfection"
"Feedback over speculation"
"Working code beats documentation"

Common objections

"But what about code quality?"

Code quality matters, but:

  • Quality without shipping = 0 value
  • Shippable code > perfect code in a drawer
  • Iteration improves quality naturally
  • AI-generated code is often clean

GSD approach:

  1. Ship working version
  2. Get real feedback
  3. Improve based on usage
  4. Refactor when patterns emerge

"But what about technical debt?"

Technical debt exists, but:

  • Unshipped code is also "debt" (opportunity cost)
  • Early feedback reduces wrong decisions
  • It is easier to refactor a small, working system

GSD approach:

  1. Accept some debt for speed
  2. Track debt explicitly (TODO comments, issues)
  3. Pay down debt in dedicated sessions
  4. Don't let debt block shipping

"But what about tests?"

Tests are important, but:

  • 100% coverage before shipping = slow
  • Real users will find bugs faster than unit tests
  • AI can generate tests after the fact

GSD approach:

  1. Critical paths: test first
  2. Rest: test after shipping, based on bugs
  3. Use AI to generate test cases
  4. Integration tests > unit tests for MVP

"But what about security?"

Security is critical, but:

  • Most MVPs are not attack targets
  • Standard practices (auth, HTTPS, validation) are quick to implement
  • Audit before scaling, not before launch

GSD approach:

  1. Use proven auth (NextAuth, Clerk)
  2. Use HTTPS always
  3. Validate all inputs
  4. Don't store sensitive data unnecessarily
  5. Security audit before significant scale

Case studies

Case study 1: MVP in a weekend

Code
TEXT
Problem: Validating a SaaS idea

Friday evening:
- Idea: Habit tracking tool
- Stack: Next.js + Supabase + Vercel

Saturday:
- Morning: Auth + basic data model (Supabase)
- Afternoon: Core UI (v0 → shadcn/ui)
- Evening: CRUD operations + basic charts

Sunday:
- Morning: Polish UI, add onboarding
- Afternoon: Set up Stripe (simple pricing)
- Evening: Deploy to Vercel, buy domain

Monday:
- Share on Twitter, ProductHunt, Reddit
- First 10 users signed up
- Real feedback started flowing

Total: ~20 hours to shipped MVP

Case study 2: Feature in an hour

Code
TEXT
Problem: Add PDF export for reports

Traditional approach (estimated: 2 days):
- Research PDF libraries
- Design export format
- Implement generation
- Handle edge cases
- Test thoroughly

GSD approach (actual: 1 hour):

[0:00] "Add PDF export to this report component.
       Use react-pdf or similar. Match current styling."

[0:10] AI generates working version

[0:20] Test with real data, find edge cases

[0:30] "Fix: long text overflows, images missing"

[0:40] Iterate 2 more times

[0:50] Final testing

[1:00] Commit and deploy

Result: Users can export PDFs

Getting started checklist

Before the project

  • Define ONE success metric
  • Determine MVP scope (what MUST work)
  • Choose your stack (decision time: max 30 min)
  • Set up repo with CLAUDE.md

During the build

  • Time-box every task
  • Use AI for boilerplate
  • Test often, small changes
  • Ship daily (or every 2 days max)

After shipping

  • Collect feedback actively
  • Respond to bugs within <24h
  • Prioritize based on data
  • Celebrate wins 🎉

GSD tool pricing

ToolFree tierPro
Claude Code$20/mo
Cursor2 weeks$20/mo
GitHub CopilotStudents$10/mo
v0200 credits$20/mo
VercelHobby$20/mo
Supabase500MB$25/mo

Minimal GSD stack cost: ~$50-100/mo

FAQ - Frequently asked questions

Is GSD only for side projects?

No, GSD works in any context where:

  • Fast feedback is valuable
  • Iteration is possible
  • Perfection is not a compliance requirement

In corporate environments you can use GSD for prototypes, MVPs, and internal tools.

How to convince your team to adopt GSD?

  1. Start with yourself - show results
  2. Use it on a small project as proof
  3. Measure and present metrics (time to ship)
  4. Gradually introduce practices

What if AI generates bad code?

  1. Provide better context
  2. Break the task into smaller pieces
  3. Ask for an explanation of the approach
  4. Iterate with specific feedback
  5. If it still does not work - write that piece yourself

How to balance GSD with "proper engineering"?

Code
TEXT
Phase 1 (MVP): 100% GSD
Phase 2 (PMF): 70% GSD, 30% engineering
Phase 3 (Scale): 50% GSD, 50% engineering
Phase 4 (Mature): 30% GSD, 70% engineering

GSD is for quickly discovering what to build. Engineering is for building it well.

Is GSD the same as "vibecoding"?

Similar philosophies, different emphasis:

  • Vibecoding: Flow state, intuition, creative coding
  • GSD: Outcome-focused, metric-driven, shipping

You can combine both - vibecoding is GSD in a flow state.

How to avoid burnout at a fast pace?

  1. Time-box sessions (max 4h of focused work)
  2. Celebrate small wins
  3. Take regular breaks
  4. Don't work weekends (unless it is a passion project)
  5. Ship consistently > ship constantly