You Aint Gonna Need It

YAGNI (You Ain't Gonna Need It)

Overview

Don't implement something until you actually need it.

Every feature has a cost: code to write, tests to maintain, complexity to manage. Speculative features often go unused while creating real burden.

When to Use

• Adding features "users might want later"
• Building "production-ready" infrastructure upfront
• Adding flexibility "in case requirements change"
• Implementing patterns "because best practices"
• Creating abstractions for hypothetical use cases

The Iron Rule

NEVER build features until they're actually required.

No exceptions:

• Not for "users will probably want this"
• Not for "it's easy to add now"
• Not for "production systems need this"
• Not for "best practices say include this"

Detection: The "Might Need" Smell

If your justification includes "might", "probably", "eventually", or "in case", STOP:

// ❌ VIOLATION: Asked for 3 endpoints, built 15
// Request: GET/POST/DELETE todos
// Built: pagination, filtering, sorting, soft delete, restore,
//        rate limiting, health checks, metrics, audit logs,
//        batch operations, search, tags, priorities, due dates...

// ✅ CORRECT: Build exactly what was asked
app.get('/todos', (req, res) => { /* list todos */ });
app.post('/todos', (req, res) => { /* create todo */ });
app.delete('/todos/:id', (req, res) => { /* delete todo */ });

The Cost of Speculative Features

Every unneeded feature costs:

Correct Pattern: Minimal First

Build the minimum that solves the actual problem:

// ❌ YAGNI VIOLATION: "Production-ready" todo API
// - Zod validation with inference
// - Pagination with cursors
// - Full-text search
// - Soft delete + restore
// - Rate limiting
// - Request tracing
// - Health endpoints
// - Graceful shutdown
// - Structured logging
// ... for a simple todo list

// ✅ CORRECT: What was actually requested
interface Todo {
  id: string;
  title: string;
  completed: boolean;
}

const todos: Todo[] = [];

app.get('/todos', (req, res) => res.json(todos));

app.post('/todos', (req, res) => {
  const todo = { id: crypto.randomUUID(), title: req.body.title, completed: false };
  todos.push(todo);
  res.status(201).json(todo);
});

app.delete('/todos/:id', (req, res) => {
  const index = todos.findIndex(t => t.id === req.params.id);
  if (index === -1) return res.status(404).json({ error: 'Not found' });
  todos.splice(index, 1);
  res.status(204).send();
});

// Add pagination WHEN users have enough todos to need it
// Add search WHEN users ask for search
// Add rate limiting WHEN there's abuse

Pressure Resistance Protocol

1. "Production Systems Need This"

Pressure: "Real production apps have logging, monitoring, health checks..."

Response: Add production features when going to production. Not during prototyping.

Action: Build MVP first. Add infrastructure when deploying for real.

2. "It's Easy to Add Now"

Pressure: "While I'm here, might as well add sorting and filtering"

Response: Easy to add now = easy to add later. Don't pay the maintenance cost until needed.

Action: Add it when someone actually needs it.

3. "Best Practices Say..."

Pressure: "Best practices recommend pagination, rate limiting, etc."

Response: Best practices are for problems you have. Don't solve problems you don't have.

Action: Follow best practices for your actual requirements.

4. "Users Will Want This"

Pressure: "Users will probably want to filter by date"

Response: "Probably" is not a requirement. Wait for actual user requests.

Action: Ship without it. Add when users actually ask.

Red Flags - STOP and Reconsider

If you notice ANY of these, you're violating YAGNI:

• "While I'm at it, I'll also add..."
• "Users might want to..."
• "In case we need to..."
• "Let's make it production-ready"
• "Best practices recommend..."
• Building abstractions for single use cases
• Adding configuration for things that won't change

All of these mean: Stop. Build only what's required.

What YAGNI Is NOT

YAGNI doesn't mean:

• Write bad code (quality is always needed)
• Skip error handling (that's required)
• Ignore security (that's required from day 1)
• Avoid good structure (clean code is required)

YAGNI means: Don't add features and capabilities until they're needed.

Quick Reference

Common Rationalizations (All Invalid)

The Bottom Line

Build what's needed. Nothing more.

When tempted to add "just one more feature": stop, check if it's required NOW, ship without it. The best code is code you didn't have to write.