sdlc-throwaway-projects

name	sdlc-throwaway-projects
description	Planning throwaway/prototype projects: rapid prototyping, vibe coding workflows, MVP planning, spike solutions, PoC validation, hackathon prep, AI-assisted development, lean canvas, assumption mapping, time-boxing, graduation path (throwaway → production), decision frameworks for keep vs discard vs graduate, tech stack selection for speed, common pitfalls, and integration with 2026 AI coding tools (Cursor, Lovable, Bolt, Replit, v0, Claude Code, Gemini CLI).
version	1.0.0-moderate
author	Dinoudon
license	MIT
platforms	["linux","macos","windows"]
metadata	{"hermes":{"tags":["sdlc","throwaway","prototype","mvp","spike","poc","vibe-coding","rapid-prototyping","hackathon","proof-of-concept","ai-assisted","lean-startup","validation","experiment"],"related_skills":["sdlc-spike","sdlc-prd-to-production","sdlc-architecture-design","sdlc-testing-qa"]}}

Throwaway Projects

Planning throwaway/prototype projects: rapid prototyping, vibe coding, MVP planning, spike solutions, decision frameworks for keep vs discard.

When to Use

Trigger when user:

• Needs to validate an idea quickly
• Mentions prototype, MVP, spike, PoC, demo, hackathon
• Wants to explore a new tech stack
• Needs proof-of-concept for stakeholder buy-off
• Asks "should we build this?"
• Wants to learn a technology by building something real
• Preparing for hackathon or demo day

Step 1: Throwaway Project Taxonomy

Types Compared

Type	Purpose	Lifespan	Fidelity	End State
Spike	Answer technical question	Hours–days	Low	Knowledge, discard
Prototype	Explore UX/interaction	Days–weeks	Medium	Feedback, discard
PoC	Prove feasibility	Days–weeks	Medium	Decision, discard
MVP	Test market demand	Weeks–months	High	Metrics, iterate or kill
Demo	Show possibility	Hours–days	Surface-level	Impress, discard
Hackathon	Build in time-box	24–48h	Variable	Pitch, maybe continue

When to Pick Which

Need to answer "can we do X?" → Spike
Need to answer "should we do X?" → Prototype
Need to prove "X works" → PoC
Need to test "will people pay for X?" → MVP
Need to show "X is possible" → Demo
Need to build "something in 48h" → Hackathon project

Step 2: Planning Framework

Lean Canvas (1-page business model)

+------------------+------------------+------------------+
| PROBLEM          | SOLUTION         | UNIQUE VALUE      |
| Top 3 problems   | Top 3 features   | Single clear msg  |
|                  |                  |                   |
+------------------+------------------+
| KEY METRICS      | UNFAIR ADVANTAGE |
| Key activities   | Can't be easily  |
| to measure       | copied           |
+------------------+------------------+
| CHANNELS         | CUSTOMER SEGMENTS|
| Path to          | Target audience  |
| customers        | Early adopters   |
+------------------+------------------+
| COST STRUCTURE                  | REVENUE STREAMS           |
| Fixed + variable costs          | Revenue model             |
+---------------------------------+---------------------------+

One-Pager Template

# [Project Name]

## Hypothesis
We believe [target users] have [problem] and will [desired action] if we build [solution].

## Validation Criteria
- [Metric 1]: [target] — proves problem is real
- [Metric 2]: [target] — proves solution works
- [Metric 3]: [target] — proves willingness to pay/engage

## Scope
### In Scope
- [Feature 1]
- [Feature 2]
- [Feature 3]

### Out of Scope
- [Explicitly NOT building]
- [Deferred to future]

## Timeline
- Day 1-2: [Phase 1]
- Day 3-4: [Phase 2]
- Day 5: [Testing + decision]

## Exit Criteria
- SUCCESS: [What success looks like]
- PIVOT: [What pivot looks like]
- KILL: [What failure looks like]

Assumption Mapping

Map assumptions on two axes: certainty (how sure are we?) and importance (how critical?).

HIGH IMPORTANCE
     |
     |  [Validate FIRST]    [Danger zone]
     |  High importance,     High importance,
     |  low certainty        high certainty
     |                       (still monitor)
     |
     +----------------------------------------
     |  [Ignore for now]    [Nice to have]
     |  Low importance,     Low importance,
     |  low certainty       high certainty
     |
LOW IMPORTANCE
     
     LOW CERTAINTY --------- HIGH CERTAINTY

Rule: Validate top-left quadrant first. Those assumptions can kill the project.

Risk-First Ordering

1. List all assumptions
2. Rank by: Impact if wrong × Likelihood of being wrong
3. Build spike/prototype to test #1 assumption FIRST
4. If assumption fails → pivot or kill early
5. If assumption holds → move to #2

Step 3: Speed-Optimized Workflow

Vibe Coding Principles

1. Describe, don't code — natural language prompts
2. Iterate fast — prompt → review → adjust → repeat
3. Accept imperfection — "good enough" beats "perfect"
4. Ship and test — get user feedback ASAP
5. Save often — commit after every working change

AI-Assisted Prototype Workflow

Phase 1: PLAN (10% of time)
├── Write one-pager
├── Map assumptions
├── Pick top 1-2 to validate
└── Choose tech stack

Phase 2: BUILD (60% of time)
├── Prompt AI for scaffold
├── Iterate on core feature ONLY
├── Skip auth, error handling, edge cases
├── Commit after each working feature
└── Test manually as you go

Phase 3: VALIDATE (20% of time)
├── Show to 3-5 target users
├── Collect structured feedback
├── Measure against validation criteria
└── Document findings

Phase 4: DECIDE (10% of time)
├── Score: kill / pivot / keep / graduate
├── If keep: plan graduation path
├── If kill: archive learnings
└── Retrospective

Prompt Patterns for Prototypes

Scaffold prompt:
"Create a [type] app with [framework]. Include [feature 1], [feature 2]. 
Skip auth, tests, and error handling. Use mock data."

Iteration prompt:
"The [component] should [change]. Keep everything else the same."

Debug prompt:
"It's broken: [error]. Fix just this issue, don't refactor."

Feature prompt:
"Add [feature] to the existing code. Minimal changes only."

No-Setup Tools for Speed

Need	Tool	Setup Time
Web app	Lovable / Bolt.new	0 min
UI components	v0 by Vercel	0 min
Backend API	Replit	2 min
Mobile app	Lovable + Capacitor	5 min
CLI tool	Claude Code	0 min
Data pipeline	Cursor + Python	5 min
Landing page	v0 / Bolt	0 min

Step 4: Tech Stack Selection

Decision Criteria

Criterion	Weight	Questions
Setup time	HIGH	How fast from zero to running?
Disposability	HIGH	Can I throw it away easily?
Learning curve	MEDIUM	Do I already know this?
Deployment speed	MEDIUM	How fast to get it live?
Cost	LOW-MED	Free tier available?
Fidelity	LOW	Does it look "real enough"?

Stack Recommendations

Web App (non-coder):
  → Lovable or Bolt.new
  → No setup, visual editor, instant deploy

Web App (developer):
  → Cursor + Next.js/React
  → Or Vite + any framework
  → Fast iteration, full control

Mobile App:
  → Lovable + Capacitor (web → mobile)
  → Or Flutter + Cursor (if know Dart)

API/Backend:
  → Replit (instant)
  → Or Hono/Express + Cursor

CLI Tool:
  → Claude Code / Gemini CLI
  → Node.js or Python script

Data/ML:
  → Cursor + Python + Jupyter
  → Google Colab for zero-setup

Landing Page:
  → v0 by Vercel (React/Tailwind)
  → Or Bolt.new (full page)

Anti-Patterns

DON'T:
- Use unfamiliar frameworks "to learn" during a time-boxed prototype
- Set up CI/CD for throwaway projects
- Write comprehensive tests before validating the idea
- Pick microservices architecture for a prototype
- Optimize for scale before validating demand
- Spend >20% of time on styling/polish

DO:
- Use what you know
- Use what's fastest to deploy
- Mock everything that's not the core hypothesis
- Accept ugly if functional
- Ship before it's "ready"

Step 5: Time-Boxing

Hard Limits

Project Type	Max Duration	Extension Policy
Spike	2 days	None — answer or abandon
Prototype	1 week	+3 days with justification
PoC	2 weeks	+1 week with stakeholder OK
MVP	4 weeks	+2 weeks with metrics
Demo	2 days	None
Hackathon	48 hours	None

Daily Check-In

Morning (5 min):
1. What's the ONE thing that matters today?
2. What's blocking it?
3. Am I still on scope?

Evening (5 min):
1. Did I hit today's goal?
2. What did I learn?
3. Scope creep check: did I add anything not in plan?

Progress Tracking

## Day 1
- [x] Set up project scaffold
- [x] Core feature v1
- [ ] Test with mock data
- Notes: [learnings]

## Day 2
- [ ] Iterate based on testing
- [ ] Add secondary feature
- [ ] Show to first user

Step 6: Quality Gates

"Good Enough" Criteria

For Spike:
- Question answered definitively
- Approach validated or invalidated
- Decision documented

For Prototype:
- Core interaction works
- User can complete primary task
- Feedback collected from 3+ users

For PoC:
- Technical feasibility proven
- Performance acceptable for demo
- Integration points identified

For MVP:
- 10+ real users tried it
- Core metric measured
- Retention signal (or clear lack thereof)

What to Skip in Throwaway Projects

SKIP:
- Comprehensive error handling
- Loading states and edge cases
- Accessibility (unless testing with disabled users)
- Performance optimization
- Code documentation
- CI/CD pipeline
- Monitoring and alerting
- Multi-environment setup
- Database migrations
- API versioning

DON'T SKIP:
- Basic input validation (prevents crashes)
- Core user flow (the thing you're testing)
- Data persistence (if testing over multiple days)
- Basic security (don't expose secrets)

Step 7: Decision Framework

Keep vs Discard vs Graduate

After validation, score each dimension (1-5):

IMPACT:      Did users care? (engagement, feedback)
FEASIBILITY: Was it buildable? (technical challenges)
STRATEGIC:   Does it fit our goals? (alignment)
COST:        Can we maintain it? (ongoing effort)

Score:
- 16-20: GRADUATE → production path
- 11-15: PIVOT   → adjust and re-test
- 6-10:  KILL    → archive learnings
- 4-5:   ABORT   → stop immediately

Graduation Checklist

When throwaway becomes real:
□ Add proper error handling
□ Write tests for core flows
□ Security review (OWASP basics)
□ Set up CI/CD
□ Add logging and monitoring
□ Document architecture
□ Refactor hot paths
□ Add proper auth
□ Database migrations
□ Performance baseline
□ Code review by another dev
□ Deployment strategy (staging → prod)

Archive Process (when killing)

## Project Archive: [Name]

### What We Built
[Brief description]

### What We Learned
- [Learning 1]
- [Learning 2]

### Why We Killed It
[Reasons with data]

### Reusable Assets
- [Code snippet / pattern]
- [User research]
- [Design assets]

### Date: [date]
### Decision makers: [names]

Step 8: Common Pitfalls

1. Scope Creep

Symptom: "While I'm at it, let me also add..."
Fix: Stick to one-pager. New ideas go to "future ideas" list.

2. Sunk Cost Fallacy

Symptom: "I've spent 2 weeks on this, can't stop now."
Fix: Time-box is sacred. Kill criteria defined upfront.

3. Premature Optimization

Symptom: "Let me refactor this for performance."
Fix: It's throwaway. If it works, ship it.

4. Wrong Fidelity Level

Symptom: Spending days on pixel-perfect UI for a PoC.
Fix: Match fidelity to project type. PoC ≠ production UI.

5. Not Testing with Real Users

Symptom: "I think it works well."
Fix: Show to 3+ target users before deciding. Always.

6. Over-Engineering Prototypes

Symptom: Setting up microservices, event buses, for a prototype.
Fix: Monolith. Single file if possible. Mock everything.

7. AI Code Blindness

Symptom: Accepting all AI output without review.
Fix: At minimum, understand the core logic. Run the code.

8. Ignoring the Hypothesis

Symptom: Building features instead of testing assumptions.
Fix: Every feature maps to an assumption. No assumption = no feature.

Step 9: Templates

Spike Ticket

## Spike: [Question]

### Question
[Specific technical question to answer]

### Time-box
[2 days max]

### Approach
1. [Step 1]
2. [Step 2]

### Success Criteria
- Clear yes/no answer
- Approach documented
- Risks identified

### Outcome
[Fill after spike: answer, recommendation, open questions]

Prototype Review

## Prototype Review: [Name]

### Users Tested: [count]
### Date: [date]

### Feedback Summary
| Theme | Frequency | Severity | Action |
|-------|-----------|----------|--------|
| [issue] | [how many] | [high/med/low] | [fix/pivot/ignore] |

### Key Quotes
> "[user quote]"
> "[user quote]"

### Metrics vs Targets
| Metric | Target | Actual | Pass? |
|--------|--------|--------|-------|
| [metric] | [target] | [actual] | ✓/✗ |

### Decision
□ Graduate  □ Pivot  □ Kill

### Next Steps
[action items]

MVP Tracker

## MVP: [Name]

### Hypothesis
[What we believe]

### Week 1
- [ ] Core feature live
- [ ] 5 users recruited
- [ ] Tracking setup

### Week 2
- [ ] 10 users tried it
- [ ] Feedback collected
- [ ] Iterate on top issue

### Week 3
- [ ] 20+ users
- [ ] Core metric measured
- [ ] Retention check

### Week 4
- [ ] Decision: scale / pivot / kill
- [ ] If scale: graduation plan
- [ ] If kill: archive learnings

Retrospective Template

## Retrospective: [Project Name]

### What Went Well
- [positive 1]
- [positive 2]

### What Could Improve
- [improvement 1]
- [improvement 2]

### Key Learnings
- [learning 1]
- [learning 2]

### Time Spent vs Estimate
- Estimated: [X days]
- Actual: [Y days]
- Variance: [+/- Z days]
- Reason: [why]

### Would We Do It Again?
[Yes/No + why]

### Reusable for Future
- [pattern/template/tool]

Integration with Vibe Coding

2026 AI Tools for Throwaway Projects

Best for NON-CODERS building prototypes:
→ Lovable: visual editor, auth, full-stack
→ Bolt.new: fast prototyping, generous free tier
→ Replit: all-in-one, zero setup

Best for DEVELOPERS building prototypes:
→ Cursor: multi-file editing, model flexibility
→ Claude Code: terminal agent, deep codebase context
→ v0 by Vercel: UI components (React/Tailwind)

Best for TEAMS:
→ Windsurf: fixed price, strong agent mode
→ GitHub Copilot: works in most IDEs

Prompt Engineering for Prototypes

Rule 1: Be specific about scope
  BAD:  "Build me a todo app"
  GOOD: "Build a todo app with add/delete/complete. 
         Use React + localStorage. No auth, no tests."

Rule 2: Describe the constraint
  BAD:  "Make it fast"
  GOOD: "This is a 2-day prototype. Skip error handling."

Rule 3: Iterate in small steps
  BAD:  "Build the entire dashboard"
  GOOD: "Show a table of 5 mock users with name/email/status"

Rule 4: Ask for alternatives
  "Show me 2 approaches for [feature]. I'll pick one."

Rule 5: Use AI for planning too
  "I want to validate [idea]. Help me write a lean canvas 
   and identify the riskiest assumption."

Iteration Loop

1. PROMPT   → Describe what you want
2. REVIEW   → Check output (run it!)
3. ADJUST   → "Change X to Y, keep Z"
4. COMMIT   → git commit -m "working feature"
5. REPEAT   → Next feature or refinement

Time per iteration: 2-15 minutes
Iterations per hour: 4-30

Step 10: Validation Methods

Customer Discovery (Mom Test)

RULES:
1. Talk about THEIR life, not your idea
   BAD:  "Would you use an AI meal planner?"
   GOOD: "Tell me about how you plan meals currently."

2. Ask about SPECIFIC past behavior
   BAD:  "Would you pay for this?"
   GOOD: "Have you ever paid for a meal planning service?"

3. Ask about problems, not your solution
   BAD:  "Wouldn't it be great if AI planned your meals?"
   GOOD: "What's the hardest part about meal planning?"

4. Get commitment, not compliments
   BAD:  "That sounds cool!" (compliment)
   GOOD: "Can I sign up now?" (commitment)

Pretotyping Methods

Before building anything, test if people WANT it:

1. LANDING PAGE
   - One page, one message, one CTA (email signup)
   - Drive traffic: social media, Reddit, HN
   - 5%+ conversion = strong signal
   - Tools: Carrd.co, v0, Bolt.new

2. FAKE DOOR TEST
   - Add button for feature that doesn't exist
   - Click → "Coming soon — sign up for early access"
   - High click rate = build it
   - Works best in existing products

3. SMOKE TEST
   - Ad campaign for non-existent product ($50-200 budget)
   - Click → landing page → signup
   - CTR > 2%, signup rate > 5% = green light
   - Run for 3-7 days max

4. SOCIAL MEDIA TEST
   - Post describing the product
   - Measure: likes, comments, DMs, signups
   - "Would you use this?" + link to waitlist

User Testing Script

SETUP (2 min):
"Hi [name], thanks for trying this out.
I'm testing the product, not testing you.
Please think out loud as you use it."

TASKS (10-15 min):
1. "[Task instruction]"
   - Observe: what they do, where they struggle
   - Ask: "What are you thinking?"

2. "[Task instruction]"
   - Observe: completion rate
   - Ask: "Is this what you expected?"

QUESTIONS (5 min):
- "What was confusing?"
- "What would you change?"
- "Would you use this? Why/why not?"
- "Would you pay for this? How much?"
- "Who else should I talk to?"

RULES:
- Don't explain — let them figure it out
- Silence is OK — don't fill it
- Record sessions (with permission)
- 5 users find 80% of usability issues

Step 11: Graduation Deep Dive

When Throwaway Becomes Real

GRADUATION TRIGGERS (need 2+):
  ✓ Users actively asking "when can I use this?"
  ✓ At least 1 user willing to pay
  ✓ Core metric shows traction
  ✓ Stakeholders want to invest
  ✓ Technical feasibility proven

ANTI-TRIGGERS (none of these are valid reasons):
  ✗ "We already built it" (sunk cost)
  ✗ "It's almost done" (famous last words)
  ✗ "Users said it was cool" (compliment ≠ commitment)
  ✗ "I think it could work" (not validated)

Graduation Checklist

## Phase 1: Foundation (Week 1-2)
- [ ] Code review by another developer
- [ ] Add proper error handling
- [ ] Add input validation
- [ ] Security review (OWASP basics)
  - [ ] No secrets in code
  - [ ] SQL injection prevention
  - [ ] XSS prevention
  - [ ] Proper auth
- [ ] Set up proper database
- [ ] Environment variables

## Phase 2: Quality (Week 3-4)
- [ ] Tests for core flows (unit + integration)
- [ ] CI/CD pipeline (lint, test, deploy)
- [ ] Documentation (README, API docs)
- [ ] Code documentation

## Phase 3: Operations (Week 5-6)
- [ ] Logging and monitoring
- [ ] Staging + production environments
- [ ] Performance baseline
- [ ] Rollback plan

## Phase 4: Launch (Week 7-8)
- [ ] User documentation
- [ ] Onboarding flow
- [ ] Support process
- [ ] Analytics setup

Refactoring Strategy

PRIORITY ORDER:
1. Security issues (fix immediately)
2. Data integrity (fix before launch)
3. Core logic (refactor for maintainability)
4. Error handling (add before scaling)
5. Performance (optimize when needed)
6. Code style (last priority)

RULES:
- Refactor in small, testable increments
- Write tests BEFORE refactoring
- One refactor per commit
- Verify behavior doesn't change
- Don't refactor what you'll delete soon

Step 12: Case Studies

Case Study 1: Weekend Prototype → Real Product

CONTEXT: Solo developer, idea for task management app
TIMELINE: 3 days

Day 1 (8h):
- Used Lovable to scaffold app
- Core feature: drag-and-drop task board
- Prompt: "Create a Kanban board with 3 columns. 
  Tasks can be dragged between columns. Use localStorage."
- Result: Working prototype in 4 hours
- Showed to 5 friends, collected feedback

Day 2 (6h):
- Iterated on feedback: added due dates, labels
- Used Lovable prompts for each feature
- Committed after each working feature
- Created landing page with v0

Day 3 (4h):
- Shared landing page on Reddit (r/productivity)
- 50 signups in 24 hours
- 3 users willing to pay $5/mo
- DECISION: Graduate

GRADUATION (4 weeks):
- Moved from Lovable to Cursor + Next.js
- Added proper auth (Clerk)
- Added database (Supabase)
- Added tests (Playwright)
- Launched on Product Hunt
- Result: 200 users, $500 MRR

KEY LEARNINGS:
- Lovable was perfect for validation speed
- Graduation path took 4x longer than prototype
- User feedback shaped the product more than the plan
- Landing page test saved months of building wrong thing

Case Study 2: Spike → Kill Decision

CONTEXT: Team of 3, exploring real-time collaboration feature
TIMELINE: 2 days

Day 1 (6h):
- Spike question: "Can we use WebRTC for real-time sync?"
- Used Cursor + Yjs library
- Tested with 2 browsers, basic sync worked
- BUT: conflict resolution was complex

Day 2 (6h):
- Deep dive on conflict resolution
- Tested with 5+ concurrent users
- Result: Works for simple cases, breaks for complex
- Performance: 200ms latency (acceptable)
- BUT: 3 weeks estimated to production-ready

DECISION: Kill
- Reason: 3 weeks effort for feature users hadn't asked for
- Alternative: simpler polling-based sync (2 days)
- Archived: WebRTC learnings, Yjs patterns
- Reused: polling approach in production (2 days vs 3 weeks)

KEY LEARNINGS:
- Spike saved 3 weeks of wasted development
- Technical feasibility ≠ business justification
- Simpler alternative existed
- Spike output: clear recommendation with data

Case Study 3: Wizard of Oz → MVP

CONTEXT: AI-powered recipe recommendation app
TIMELINE: 2 weeks

Week 1: Wizard of Oz
- Built frontend with Lovable (photo upload → recipe suggestions)
- Backend: human (developer) manually analyzed photos and wrote recipes
- 10 test users, all believed it was automated
- Result: 8/10 users said "this is amazing"
- Key learning: users cared about speed, not AI accuracy

Week 2: Decision + Transition
- Manual process took 5 min per user (too slow to scale)
- BUT: user demand was strong
- DECISION: Build real AI backend
- Used Claude API for recipe generation
- Launched MVP to same 10 users + 10 new

RESULT:
- 15/20 users completed onboarding
- 8/20 used it 3+ times in first week
- 3/20 willing to pay $4.99/mo
- DECISION: Graduate

KEY LEARNINGS:
- Wizard of Oz proved demand before building AI
- Manual process defined the product spec perfectly
- Users valued speed over accuracy (unexpected)
- Cost of manual process = cost of AI API (roughly)

Step 13: Metrics

Validation Metrics by Project Type

SPIKE:
- Question answered: yes/no
- Time spent vs estimate
- Recommendation clarity

PROTOTYPE:
- Task completion rate (% of users who complete primary task)
- Time to complete (seconds)
- Error rate (mistakes per session)
- User satisfaction (1-5 scale)
- Net Promoter Score (would you recommend?)

MVP:
- Activation rate (% who complete onboarding)
- Retention (D1, D7, D30)
- Core action frequency (actions per user per day)
- Conversion rate (free → paid)
- Customer Acquisition Cost (CAC)
- Willingness to pay (% and amount)

LANDING PAGE:
- Visit → signup conversion rate
- Signup → waitlist conversion
- Traffic source breakdown
- Cost per signup (if paid traffic)

SMOKE TEST:
- Ad click-through rate (CTR)
- Landing page conversion
- Cost per signup
- Signup quality (engagement with follow-up)

Pivot/Kill Criteria

PIVOT when:
- Users have the problem but don't like the solution
- Some users love it, most don't (niche opportunity)
- Technical approach doesn't work, but problem is real
- Different segment shows more promise

KILL when:
- Users don't have the problem (or don't know they do)
- Users won't pay (and no viable free model)
- Technical feasibility is proven impossible
- Market is too small or too competitive
- Better alternative exists and is entrenched

METRICS THRESHOLDS (rough guide):
- Activation < 20% → pivot or kill
- D7 retention < 10% → pivot or kill
- Willingness to pay < 5% → pivot or kill
- Task completion < 30% → pivot (UX issue)
- NPS < 0 → pivot or kill

Speed Hacks Cheat Sheet

1. AI for EVERYTHING
   - Planning: "Help me write a one-pager for [idea]"
   - Scaffolding: "Create a [type] app with [features]"
   - Debugging: "Fix this error: [paste]"
   - Iteration: "Change X to Y"

2. Mock everything
   - Hardcode data instead of APIs
   - Use localStorage instead of databases
   - Skip auth (or simple password)
   - Use placeholder images

3. Skip what doesn't matter
   - No tests (for throwaway)
   - No CI/CD
   - No error handling (basic try/catch only)
   - No loading states

4. Use opinionated tools
   - Lovable/Bolt: pre-configured stack
   - Replit: zero setup
   - v0: pre-built components

5. Commit frequently
   - Every working feature = commit
   - Easy rollback if breaks
   - Never lose working state

6. Time-box ruthlessly
   - Set timer for each feature
   - Stuck > 30 min → simplify or skip
   - "Done" > "perfect"

7. Test with users early
   - Day 1: show wireframe
   - Day 2: show prototype
   - Day 3: show working feature

Step 14: Spike Methodology

Spike Types

Technical spike:
  Question: "Can we use [technology] for [purpose]?"
  Duration: 1-3 days
  Output: Technical feasibility report
  Example: "Can we use WebAssembly for real-time video processing?"

Research spike:
  Question: "What is the best approach for [problem]?"
  Duration: 2-5 days
  Output: Comparison matrix with recommendation
  Example: "What is the best auth provider for our use case?"

Integration spike:
  Question: "How does [system A] connect to [system B]?"
  Duration: 1-2 days
  Output: Working integration prototype + gotchas doc
  Example: "How does Stripe Connect handle marketplace payments?"

Performance spike:
  Question: "Can we meet [performance requirement]?"
  Duration: 2-3 days
  Output: Benchmarks + bottlenecks + optimization path
  Example: "Can we process 10K events/second with this architecture?"

Spike Report Template

# Spike: [Question]

## Context
- Why are we investigating this?
- What decision depends on this?

## Approach
- What did we try?
- What tools/libraries did we evaluate?

## Findings
- [Finding 1 with evidence]
- [Finding 2 with evidence]
- [Finding 3 with evidence]

## Recommendation
- [Clear recommendation with reasoning]
- [Trade-offs acknowledged]

## Proof
- [Link to code/repo]
- [Screenshots/benchmarks]
- [Working demo if applicable]

## Follow-up
- [ ] [Next step 1]
- [ ] [Next step 2]

Step 15: Prototype Patterns

UI Prototype

Goal: Validate user experience before building backend

Tools:
  - Figma: High-fidelity mockups
  - Framer: Interactive prototypes
  - HTML/CSS: Clickable prototype
  - React + static data: Functional prototype

Approach:
  1. Sketch key screens (paper or digital)
  2. Build clickable flow (3-5 screens)
  3. Add realistic data (not lorem ipsum)
  4. Test with 3-5 users
  5. Iterate based on feedback

Time: 1-3 days
Output: Clickable prototype + user feedback

Data Prototype

Goal: Validate data model and queries before building app

Tools:
  - Jupyter notebook: Data exploration
  - SQL: Schema design and query testing
  - Python + pandas: Data transformation
  - Sample dataset: Realistic test data

Approach:
  1. Define key entities and relationships
  2. Create sample dataset (100-1000 records)
  3. Write key queries (top 5 use cases)
  4. Test performance (indexes, joins)
  5. Validate data model supports requirements

Time: 1-2 days
Output: Schema + sample queries + performance notes

API Prototype

Goal: Validate API design before implementation

Tools:
  - OpenAPI spec: API contract
  - Mock server: Auto-generated from spec
  - Postman: API testing
  - Swagger UI: Interactive documentation

Approach:
  1. Define API contract (OpenAPI/Swagger)
  2. Generate mock server
  3. Build client against mock
  4. Test with frontend team
  5. Iterate on contract

Time: 1-2 days
Output: API spec + mock server + client feedback

Step 16: MVP Frameworks

Concierge MVP

Definition: Deliver value manually before building automation

Example: 
  - Instead of building recommendation engine, manually curate
  - Instead of building chatbot, have humans respond
  - Instead of building matching algorithm, match manually

Benefits:
  - Validate demand without engineering
  - Learn user preferences firsthand
  - Iterate faster (change manual process)
  - Build empathy for the problem

Time: 1-2 weeks
Cost: Human time only
Output: Validated demand + user insights

Wizard of Oz MVP

Definition: Appear automated to user, but operate manually behind scenes

Example:
  - User sees AI-powered analysis, human actually does it
  - User sees automated matching, human actually matches
  - User sees real-time processing, batch processing behind scenes

Benefits:
  - Test user experience without building backend
  - Validate willingness to pay
  - Learn edge cases before automating

Time: 2-4 weeks
Cost: Human time + minimal frontend
Output: Validated UX + willingness to pay

Single-Feature MVP

Definition: Build ONE feature exceptionally well

Example:
  - Dropbox: File sync (nothing else)
  - Instagram: Photo filter + share (nothing else)
  - Twitter: 140-character posts (nothing else)

Benefits:
  - Faster to market
  - Clear value proposition
  - Easier to iterate
  - Lower maintenance burden

Time: 2-4 weeks
Cost: Minimal engineering
Output: Working feature + user feedback

Step 17: Throwaway-to-Production Pipeline

Graduation Criteria

Technical criteria:
  - Core functionality works end-to-end
  - Performance meets requirements (response time, throughput)
  - Security basics implemented (auth, input validation)
  - Error handling covers known failure modes
  - Data persistence is reliable
  - API contract is stable

Business criteria:
  - User feedback is positive (>80% satisfaction)
  - Key metrics show promise (engagement, retention)
  - Willingness to pay validated (if applicable)
  - Competitive advantage identified
  - Scale requirements understood
  - Go/no-go decision documented

Process criteria:
  - Code reviewed by at least one engineer
  - Test coverage for critical paths (>60%)
  - Documentation exists (README, API docs)
  - Deployment process documented
  - Monitoring and alerting basic setup
  - Rollback plan exists

Refactoring Playbook

Phase 1: Assessment (1-2 days)
  - Code review (identify technical debt)
  - Architecture review (identify structural issues)
  - Test coverage analysis
  - Performance profiling
  - Security audit

Phase 2: Foundation (1-2 weeks)
  - Set up proper project structure
  - Add comprehensive tests
  - Implement CI/CD pipeline
  - Set up monitoring and logging
  - Document architecture decisions

Phase 3: Refactoring (2-4 weeks)
  - Extract reusable components
  - Implement proper error handling
  - Add input validation and sanitization
  - Optimize database queries
  - Implement caching strategy

Phase 4: Hardening (1-2 weeks)
  - Security penetration testing
  - Load testing
  - Chaos engineering (failure injection)
  - Documentation completion
  - Runbook creation

Phase 5: Launch (1 week)
  - Staged rollout (1% then 10% then 100%)
  - Monitoring dashboards
  - Alert configuration
  - On-call rotation setup
  - Post-launch review

Step 18: Experimentation Culture

Experiment Design

Hypothesis format:
  "If we [change], then [metric] will [direction] by [amount], 
  because [reasoning]."

Example:
  "If we add a free tier, then signups will increase by 50%, 
  because developers can try before committing budget."

Variables:
  Independent: What we change (free tier)
  Dependent: What we measure (signups)
  Controlled: What stays the same (product, marketing)

Sample size:
  Baseline: Current signups/month
  MDE: Minimum detectable effect (50% increase)
  Significance: 95% confidence
  Power: 80%
  
  Use calculator: Evan Miller A/B test calculator

Duration:
  Minimum: 2 full business cycles (2 weeks)
  Maximum: 6 weeks (diminishing returns)
  Consider: Seasonality, day-of-week effects

Experiment Tracking

Experiment log:
  | ID | Hypothesis | Start | End | Result | Learning |
  |----|------------|-------|-----|--------|----------|
  | EXP-001 | Free tier increases signups | Jan 1 | Jan 15 | +62% | Strong signal |
  | EXP-002 | Shorter onboarding improves activation | Jan 15 | Jan 29 | +18% | Moderate signal |
  | EXP-003 | Social proof increases conversion | Feb 1 | Feb 14 | -3% | No effect |

Review cadence:
  - Daily: Monitor for anomalies
  - Weekly: Review running experiments
  - Bi-weekly: Plan next experiments
  - Monthly: Retrospective on experiment velocity

Step 19: Risk Management

Risk Register

| Risk | Probability | Impact | Mitigation | Owner |
|------|-------------|--------|------------|-------|
| Tech does not work | Medium | High | Spike first, validate early | Tech lead |
| No user demand | Medium | High | User interviews, concierge MVP | Product |
| Scope creep | High | Medium | Strict timeboxing, daily standups | PM |
| Key person leaves | Low | High | Document decisions, pair programming | Team |
| Integration fails | Medium | Medium | Spike integrations, have fallbacks | Tech lead |

Risk review:
  - Daily: Check risk indicators
  - Weekly: Review risk register
  - At milestones: Reassess all risks
  - At completion: Final risk assessment

Step 20: Communication Templates

Project Kickoff Email

Subject: [Project Name] Kickoff

Team,

We are starting a throwaway project to validate [hypothesis].

Goal: [One sentence goal]
Timeline: [X days/weeks]
Decision: [What we will decide at the end]

Team:
  - [Name]: Role
  - [Name]: Role

Key dates:
  - Kickoff: [Date]
  - Daily standup: [Time] (15 min)
  - Demo: [Date]
  - Decision: [Date]

Repo: [Link]
Docs: [Link]
Slack: [Channel]

Let us move fast and learn.

Decision Email

Subject: [Project Name] Decision

Team,

Based on our throwaway project, here is the decision:

Decision: [GO / NO-GO / PIVOT]

Evidence:
  - [Key finding 1]
  - [Key finding 2]
  - [Key finding 3]

Metrics:
  - [Metric 1]: [Result]
  - [Metric 2]: [Result]

Next steps:
  - [If GO]: [What happens next]
  - [If NO-GO]: [What we learned, what we will try instead]
  - [If PIVOT]: [What we are changing and why]

Lessons learned:
  - [Lesson 1]
  - [Lesson 2]

Repo: [Link] (archived)
Report: [Link]

Step 21: Speed Hacks Cheat Sheet

SETUP:
  - Use templates (create-next-app, create-react-app)
  - Use managed services (Supabase, PlanetScale, Vercel)
  - Use component libraries (shadcn/ui, Tailwind UI)
  - Copy-paste from previous projects

DEVELOPMENT:
  - Build vertical slice first (one feature end-to-end)
  - Use hardcoded data before database
  - Use console.log before proper logging
  - Skip authentication initially (add later)
  - Use placeholder UI (canned responses)

TESTING:
  - Manual testing for throwaways
  - Automated tests only for critical paths
  - Smoke tests for deployment
  - User testing over unit testing

DEPLOYMENT:
  - One-click deploy (Vercel, Railway, Render)
  - Managed database (Supabase, PlanetScale)
  - Environment variables in platform
  - No custom CI/CD initially

DOCUMENTATION:
  - README with setup instructions
  - Decision log (why, not what)
  - Screenshot/video of working demo
  - Lessons learned document

Step 22: Validation Experiments

Landing Page Test

Goal: Validate demand before building product

Setup:
  - Create landing page (Carrd, Webflow, Framer)
  - Value proposition (headline, subheadline, CTA)
  - Email capture (signup form)
  - Analytics (Plausible, PostHog)

Traffic sources:
  - Reddit (relevant subreddits)
  - Hacker News (Show HN)
  - Twitter/X (tech community)
  - LinkedIn (target audience)
  - Google Ads (search intent)

Metrics:
  - Visitors: Total unique visitors
  - Conversion: Visitors who signed up
  - Cost per signup: Ad spend / signups
  - Qualitative: Feedback from comments, emails

Decision criteria:
  - >5% conversion: Strong signal (build it)
  - 2-5% conversion: Moderate signal (iterate on messaging)
  - <2% conversion: Weak signal (reconsider or pivot)

Time: 1-2 weeks
Cost: $0-500 (ads optional)

Smoke Test

Goal: Test willingness to pay before building

Setup:
  - Landing page with pricing
  - Payment button (Stripe checkout)
  - "Coming soon" page after payment
  - Refund immediately + email explanation

Metrics:
  - Click-through rate on pricing
  - Payment attempts
  - Successful payments
  - Refund requests

Decision criteria:
  - >10% click pricing: Strong interest
  - >2% attempt payment: Strong signal
  - Any successful payment: Build it immediately

Ethics:
  - Be transparent ("We are testing demand")
  - Refund immediately
  - Offer early access when you build
  - Do not charge without delivering value

Step 23: Throwaway Project Anti-Patterns

Common Mistakes

Premature optimization:
  Problem: Building for scale before validating demand
  Solution: Build for 10 users, not 10 million
  
  Signs:
    - Choosing databases for performance
    - Implementing caching before measuring
    - Designing for multi-region before launch
    - Building admin dashboards before users

Gold plating:
  Problem: Adding features beyond the core hypothesis
  Solution: Ruthlessly cut scope
  
  Signs:
    - "While we are at it, let us add..."
    - Building settings/preferences pages
    - Implementing edge case handling
    - Perfecting error messages

Analysis paralysis:
  Problem: Researching instead of building
  Solution: Set a research deadline, then build
  
  Signs:
    - Reading more than 3 blog posts on a topic
    - Comparing more than 5 tools/libraries
    - Creating detailed specs before prototyping
    - Waiting for "perfect" information

Sunk cost fallacy:
  Problem: Continuing a failing project because of time invested
  Solution: Define exit criteria upfront, honor them
  
  Signs:
    - "We have already spent 2 weeks on this"
    - Ignoring negative user feedback
    - Adding features to fix fundamental problems
    - Extending timeline repeatedly

Step 24: Throwaway Project Tools

Tool Selection Matrix

Frontend prototyping:
  Speed-first: HTML + Tailwind CDN + Alpine.js
  React-first: Next.js + shadcn/ui + Tailwind
  No-code: Framer, Webflow, Carrd
  
Backend prototyping:
  Speed-first: Supabase (Auth + DB + API)
  Node-first: Express + Prisma + PostgreSQL
  Python-first: FastAPI + SQLAlchemy + PostgreSQL
  Serverless: AWS Lambda + DynamoDB

Database:
  Speed-first: Supabase (PostgreSQL hosted)
  Local-first: SQLite + Prisma
  Production-ready: PlanetScale (MySQL) or Neon (PostgreSQL)

Deployment:
  Speed-first: Vercel (frontend) + Railway (backend)
  All-in-one: Render (web + DB + workers)
  Self-hosted: Docker + DigitalOcean

Auth:
  Speed-first: Supabase Auth
  Flexible: Auth0, Clerk, Lucia
  Self-hosted: NextAuth.js, Passport.js

Step 25: Post-Mortem Template

Throwaway Project Retrospective

# Retrospective: [Project Name]

## Hypothesis
[What we were testing]

## Timeline
- Start: [Date]
- End: [Date]
- Duration: [X days/weeks]

## Decision
[GO / NO-GO / PIVOT]

## What Worked
- [Thing 1]
- [Thing 2]

## What Did Not Work
- [Thing 1]
- [Thing 2]

## Key Learnings
- [Learning 1]
- [Learning 2]

## Surprises
- [Unexpected finding 1]
- [Unexpected finding 2]

## Next Steps
- [If GO]: [What we will build]
- [If NO-GO]: [What we will try instead]
- [If PIVOT]: [What we will change]

## Archive
- Repo: [Link] (archived)
- Demo: [Link] (if still running)
- Artifacts: [Screenshots, videos, data]

## Related Skills

  - [sdlc-prd-to-production](sdlc-prd-to-production): End-to-end workflow: PRD → design doc → implementation → code review → testing → deployment → monito
  - [sdlc-product-growth](sdlc-product-growth): Product-led growth (PLG), developer-led growth, growth loops, activation funnels, A/B testing, SaaS 
  - [sdlc-architecture-design](sdlc-architecture-design): System design, C4 diagrams, API design, database schema, code architecture, ADRs, branching, depende


## Step 26: Technical Debt from Throwaways

### Managing Throwaway Code

When throwaway becomes production:

• Identify technical debt immediately
• Document shortcuts taken
• Prioritize refactoring items
• Set timeline for cleanup

Technical debt categories: Architecture debt: - Monolithic structure (need decomposition) - Tight coupling (need abstraction) - Missing patterns (need proper design)

Code debt: - No tests (need test coverage) - Copy-paste code (need DRY refactoring) - Hardcoded values (need configuration) - Poor error handling (need resilience)

Infrastructure debt: - Manual deployment (need CI/CD) - No monitoring (need observability) - No logging (need structured logging) - Single point of failure (need redundancy)

Debt tracking:

• Create tickets for each debt item
• Estimate effort (hours/days)
• Prioritize by risk and impact
• Schedule 20% of sprint capacity for debt

### Code Review for Throwaways

Review focus areas:

• Security basics (no hardcoded secrets, input validation)
• Data handling (proper encryption, access controls)
• Error handling (graceful failures, user-friendly messages)
• Performance (no obvious bottlenecks)
• Maintainability (clear structure, comments for complex logic)

Review checklist: □ No secrets in code □ Input validation present □ Error handling implemented □ Database queries parameterized □ Authentication required for sensitive endpoints □ Rate limiting on public APIs □ Logging for debugging □ README with setup instructions

## Step 27: Throwaway Project Metrics

### Success Metrics

Speed metrics:

• Time to first working prototype
• Time to user feedback
• Time to decision (go/no-go)
• Time to production (if graduating)

Learning metrics:

• Hypotheses tested
• Assumptions validated/invalidated
• User interviews conducted
• Experiments run

Quality metrics:

• User satisfaction (if tested with users)
• Technical feasibility confirmed
• Business viability assessed
• Risk reduction achieved

Efficiency metrics:

• Cost per experiment
• Developer hours per hypothesis
• Iterations before decision
• Resources consumed vs budget

## Step 28: Throwaway Project Library

### Reusable Components

Boilerplate templates:

• Next.js + Supabase (full-stack web)
• Express + PostgreSQL (API backend)
• FastAPI + SQLAlchemy (Python API)
• React Native + Expo (mobile)

UI component libraries:

• shadcn/ui (copy-paste components)
• Tailwind UI (pre-built layouts)
• Radix UI (accessible primitives)
• Headless UI (unstyled components)

Backend services:

• Supabase (auth, database, storage)
• PlanetScale (serverless MySQL)
• Upstash (serverless Redis)
• Resend (email API)

Deployment templates:

• Vercel (frontend + serverless)
• Railway (full-stack)
• Fly.io (containers)
• Render (web services + databases)

Analytics:

• PostHog (product analytics)
• Plausible (privacy-friendly web analytics)
• Mixpanel (event tracking)
• Amplitude (user analytics)

## Step 29: Throwaway vs Prototype vs MVP

### Definitions

Throwaway:

• Purpose: Answer a specific question
• Duration: Hours to days
• Quality: Lowest (functional only)
• Audience: Internal team
• Outcome: Decision (yes/no/pivot)
• Example: "Can we process video in the browser?"

Prototype:

• Purpose: Validate design or experience
• Duration: Days to weeks
• Quality: Medium (looks real, limited backend)
• Audience: Users (for testing)
• Outcome: User feedback
• Example: "Is this checkout flow intuitive?"

MVP:

• Purpose: Validate product-market fit
• Duration: Weeks to months
• Quality: Production-ready (minimal features)
• Audience: Real users (paying customers)
• Outcome: Market validation
• Example: "Will people pay for this?"

Decision framework:

• Unknown technology? → Throwaway (spike)
• Unknown UX? → Prototype
• Unknown demand? → MVP
• Unknown business model? → MVP with pricing test

Step 30: Throwaway Project Checklist

Pre-Project Checklist

□ Hypothesis clearly defined
□ Success criteria established
□ Time limit set (hours/days)
□ Scope limited to core question
□ Exit criteria defined
□ Team aligned on approach
□ Tools selected (fastest path)
□ Repository created
□ README with hypothesis

During Project Checklist

□ Working on core hypothesis only
□ No feature creep
□ Time tracking active
□ Daily standup (if multi-day)
□ Documenting learnings
□ Testing with real data/users
□ Not optimizing prematurely
□ Staying within time limit

Post-Project Checklist

□ Decision made (go/no-go/pivot)
□ Learnings documented
□ Code archived (if keeping)
□ Team retrospective done
□ Next steps defined
□ Stakeholders informed
□ Metrics recorded
□ Artifacts saved (screenshots, data)

Step 31: Throwaway Project Communication

Stakeholder Updates

Daily update template:
  Today: [What we did]
  Learnings: [What we discovered]
  Blockers: [What is blocking us]
  Tomorrow: [What we will do next]

Decision update template:
  Hypothesis: [What we tested]
  Result: [What we found]
  Evidence: [Data, feedback, metrics]
  Decision: [Go/No-go/Pivot]
  Next steps: [What happens now]

Documentation Template

# Throwaway: [Project Name]

## Hypothesis
[What we are testing]

## Approach
[How we are testing it]

## Timeline
- Start: [Date]
- End: [Date]
- Duration: [X days]

## Results
[What we found]

## Decision
[Go / No-go / Pivot]

## Learnings
- [Learning 1]
- [Learning 2]

## Next Steps
[What happens next]

## Artifacts
- [Screenshots, videos, data]
- [Link to archived code]


## Step 32: Throwaway Project Resources

### Learning Resources

Books:

• The Lean Startup (Eric Ries)
• Sprint (Jake Knapp)
• Inspired (Marty Cagan)
• Continuous Discovery Habits (Teresa Torres)

Courses:

• Y Combinator Startup School (free) -IDEO Design Thinking (online)
• Google Design Sprint (online)

Tools:

• Miro (collaboration)
• Figma (design)
• Notion (documentation)
• Loom (video updates)