First Principles

First Principles

A reasoning method, not a framework. The opposite of "this is how the industry does it". Especially valuable when:

• The conventional answer feels expensive or impossible.
• Multiple smart people disagree from analogy alone.
• The cost structure of an industry is taken as fixed and shouldn't be.

Famous applications:

• Musk on rocket cost: instead of "rockets cost $100M because that's the market price", ask "what does aluminum, fuel, electronics, and labor add up to from raw materials?". Answer: ~2% of market price. Build SpaceX.
• Aristotle: "first principles are the first basis from which a thing is known".
• Feynman: "the first principle is that you must not fool yourself — and you are the easiest person to fool".

When to use this skill

• A decision feels stuck because everyone is reasoning from "how it's always done".
• Cost or time estimates feel inflated by industry norm.
• You're considering a wild bet and need to test if it's possible (not just unprecedented).
• Diagnosing why a smart team is doing the wrong thing.

Process

1. State the question. Concrete, not vague. "Should we build our own payments?" beats "should we save on costs?".
2. List the analogies and conventional answers. ("Stripe charges 2.9%", "everyone outsources payments", "we'd need PCI compliance which costs years"). Mark them as analogies, not truths.
3. Strip to first principles. Ask "what is fundamentally required for this?". For payments: a way to authorize a card transaction, comply with regs, settle funds, handle disputes. Cost = card network fee (mostly fixed, ~1.5%) + settlement infra + compliance + risk loss. Most of "Stripe's 2.9%" is margin, not cost.
4. Reconstruct from those principles. Could you build infra at lower cost than the market? What would have to be true? At what scale does it pencil?
5. Test by inversion. Why might first-principles thinking lead you wrong here? (E.g., risk tail events you didn't price.)
6. Decide. Often the answer is still "use Stripe" — but you'll have made it deliberately, not by default.

Output format

# First-Principles Analysis · {decision}

## The conventional answer (analogies)
- {analogy 1}
- {analogy 2}

## The underlying physics / economics / regulation
1. {axiom} — {why it's a true constraint}
2. {axiom} — {why}
3. {axiom} — {why}

## Reconstruction
- If we accept only the axioms above, the cost / time / structure becomes: {derivation}
- The market price is {X}. The first-principles floor is {Y}. The gap of {X-Y} is: {margin / inefficiency / value-add}

## Decision
- Recommended: {decision}
- Why this differs from the conventional answer: {reason}
- Risks of being wrong: {3 specific risks + how we'd detect them}

Anti-patterns to reject

• "First principles" used as a cover to ignore real constraints (regulation, network effects, switching costs are real, not analogies).
• Stopping at "we could build it cheaper in theory" — without going through the reconstruction with numbers.
• Ignoring the value of the convention. Sometimes "everyone does it this way" reflects accumulated wisdom, not laziness. Test before discarding.

Constraints

• Always distinguish what's a hard constraint (physics, math, regulation) from what's a soft norm (industry practice).
• Always quantify the gap between conventional and first-principles answer.
• Output in the user's language.
• If the first-principles answer matches the conventional one, say so — that's also valuable.