YC/SV Development Framework

Decision-making framework based on principles from Y Combinator founders and Silicon Valley leaders.

THE CENTRAL QUESTION

Before any technical decision, ask:

“Does this help us make something people want?” (Paul Graham, YC motto) “Will this help the next customer pay?”

If the answer isn’t clearly YES, you probably shouldn’t do it.

CORE PRINCIPLES

1. Ship > Perfect (Michael Seibel)

"Launch something bad quickly" - Michael Seibel, YC
"If you walk away with one thing: launch something bad quickly"

• Launch MVP in days, not weeks
• Iterate based on real feedback
• Your first version MUST be embarrassing

2. Validation > Architecture (Patrick Collison)

Patrick Collison built Stripe with Ruby + MongoDB, not "elegant" technology.
"Every time there's a super elegant way to do things and a practical, pragmatic way,
we're just gonna cut the corner—at least until we validate there's actual user value."

• Ugly code that works > elegant code that doesn’t exist
• Don’t optimize prematurely
• Solve the problem first, refactor later (if necessary)

3. Do Things That Don’t Scale (Paul Graham)

Brian Chesky at Airbnb: do things manually until it hurts, then automate.
Stripe founders installed the product in person ("Collison installation").

• Manual processes are FINE at the start
• Don’t automate until the manual process is a real bottleneck
• Use “Collison installation”: set up customers manually one by one

4. Default Alive or Dead (Paul Graham)

Ask yourself: "If I don't raise more money, will I reach profitability before running out of runway?"

• If you’re “default dead”, NOTHING matters except changing that
• Fancy features are irrelevant if the business dies

5. Founder Mode (Brian Chesky)

Brian Chesky at his YC 2024 talk: the best founders are in the details.
Great leadership is presence, not absence. Know the work, not just "manage people".

• Being in the details is NOT micromanagement
• Know the code, the product, the customers

DECISION FRAMEWORK

Question 1: Is it currently working?

YES it works → DON'T TOUCH IT
"If it works, don't touch it"

Question 2: Are users/customers complaining?

NO complaints → Not a priority
YES complaints → Evaluate revenue impact

Question 3: Does it block revenue?

YES blocks revenue → P0 (do it TODAY)
NO doesn't block → P1 or P2

Question 4: How many users does it affect?

10 users who LOVE the product > 1000 who "kinda like it"
- Michael Seibel

PRIORITIES (P0/P1/P2)

P0 – Do TODAY

• Bug losing money/customers
• System down
• Exploitable security vulnerability
• Feature blocking first payment

P1 – This week

• Bug reported by paying customer
• Feature requested by multiple customers
• Technical debt causing recurring bugs

P2 – When there’s time

• Refactoring “to clean up”
• Tests for code that works
• CI/CD improvements
• Documentation

NEVER

• Rewrite something that works
• Add features nobody asked for
• “Improvements” without a real problem to solve

TECHNICAL DEBT

When to ACCEPT technical debt

Technical debt is leverage - most startups need it.

• To ship faster
• To validate hypotheses
• When the cost of NOT having it is greater than the interest

When to PAY technical debt

• When it becomes a bottleneck for new features
• When it causes recurring bugs (high “interest”)
• When 20% of the code causes 80% of the pain (Pareto)

When to IGNORE technical debt

• If the code works and nobody touches it
• If the business might die before it matters
• If it doesn’t affect customers

QUICK TECHNICAL DECISIONS

Add tests?

Tests for critical payment code: YES
Tests for UI that changes every week: NO
Tests after production bug: YES
Tests "for best practices": NO

Refactor?

If current code blocks needed feature: YES
If it "looks ugly" but works: NO
If it causes recurring bugs: YES
If it "would be more elegant": NO

Add CI/CD?

If manual deploy takes >30min: YES
If there are <10 deploys/month: NO
If deploy errors are common: YES
If the team is 1-2 people: PROBABLY NO

New dependency/framework?

Solves real problem you have TODAY: YES
"Would be useful in the future": NO
Team already knows it: BONUS
Nobody knows it: CAUTION

COMMUNICATING DECISIONS

With non-technical stakeholders (Sam Altman)

"Listen to everyone. Then make your own decision."
"It's better to make a decision and be wrong than to equivocate."

1. Listen to the business problem
2. Propose simple technical solution
3. Give realistic timeline (and meet it)
4. DON’T ask permission for technical decisions

When to say NO

• “That would require rewriting X, which works fine”
• “We can do it, but it would delay Y which is more important”
• “The simple version takes 2 days, the ‘correct’ one takes 2 weeks”

METRICS THAT MATTER

"Choose 1-2 key metrics. Decide based nearly exclusively on how tasks impact those metrics"
- Michael Seibel

For B2B SaaS:

1. MRR (Monthly Recurring Revenue)
2. Churn rate

For Marketplace:

1. GMV (Gross Merchandise Value)
2. Take rate

For Consumer:

1. DAU/MAU
2. Retention D7/D30

DON’T measure:

• Lines of code
• Test coverage (except as a signal)
• Team “velocity”
• Story points

EXECUTIVE SUMMARY

do:
  - Ship fast, iterate based on data
  - Solve real problems for real users
  - Ugly code that works > elegant code that doesn't exist
  - Manual first, automate when it hurts

dont:
  - Refactor code that works
  - Add features nobody asked for
  - Optimize before having users
  - "Best practices" without a real problem

guiding_questions:
  - "Will this help the next customer pay?"
  - "How many users are complaining about this?"
  - "What happens if we DON'T do this?"
  - "What's the simplest version that solves the problem?"

SOURCES

Principles extracted from:

• Paul Graham (YC Co-founder): paulgraham.com
• Sam Altman (ex-YC President): blog.samaltman.com
• Michael Seibel (YC Partner Emeritus, Former CEO): michaelseibel.com
• Patrick Collison (Stripe CEO): Interviews and Stripe culture
• Brian Chesky (Airbnb CEO): “Founder Mode” talk at YC 2024